On Wed, May 21, 2008 at 12:52 PM, Peter Duniho <[EMAIL PROTECTED]> wrote: >> Date: Wed, 21 May 2008 08:33:40 +0800 >> From: "Michael Ash" <[EMAIL PROTECTED]> >> >> On Tue, May 20, 2008 at 4:07 PM, Peter Duniho <[EMAIL PROTECTED]> wrote: >>> >>> But personally, it makes me nervous to have a language that allows the >>> implementation of a class to change according to other code not related >>> to >>> the class. It's one thing if you're just adding a method that you want >>> to >>> use somewhere else. But in Objective-C you can also add a method that >>> overrides a base class method, or would not normally exist in the class >>> but >>> which has meaning to some other code that might check for it. >> >> I'd just like to point out that the above applies to any OO language >> which supports both subclassing and dynamic dispatch, which is to say >> approximately all of them. Categories are certainly differently >> powerful in this regard, and as such will get you into trouble in ways >> that subclassing cannot, but subclassing already has this powerful and >> dangerous semantic that you're worried about. > > No, it doesn't. > > Each language varies a bit, of course. But in the other popular languages > that I know reasonably well -- C++, C#, Java -- a subclass does not have the > ability to touch any part of the base implementation that is not > specifically exposed by that implementation. Private members are invisible, > and other members are only overridable when the base class allows it by > making them virtual. > > There is, of course, hazard any time the base implementation makes this > allowance. But those choices can be made on a member-by-member basis, and > reliable decisions and assumptions can be made regarding the relative > dependability of the base class on the basis of what that base class exposes > to sub-classes. Many classes have _no_ overridable members and no > "protected" members, and thus completely encapsulate their implementations. > This is, in fact, the norm for these other languages.
This doesn't mean that they don't have this hazard, it just means that the creator of a class is able to mitigate it. That said, I have a difficult time emphasizing with this antagonistic point of view that users of these languages tend to have. It's as though the API writer is a sysadmin, and the API users are system users, and the users must be prevented from doing anything to adversely affect the system. I've found a cooperative approach to make a lot more sense. The reason you avoid accessing other objects' private instance variables isn't because you can't (you can do it in any C-based language, of course, regardless of the access controls you set), but because it's a bad idea and makes your code more brittle. So it's tough to see how it makes a language better because it enforces this kind of thing, when you can get essentially the same effect by simply adding a comment that says "// do not override this method". > Cocoa restrains class extension _much_ less than any of these other > languages, and in turn has a _much_ higher degree of hazard. > > It's certainly a continuum. I agree we're not talking either/or, > black/white, etc. here. Other languages aren't without their danger zones > either. It just seems to me that Cocoa goes overboard, for relatively > little payoff. Objective-C, not Cocoa, of course. Although Cocoa's designed is inextricably based on the features and capabilities of Objective-C. If the above languages are the only other OO languages you know, then the fact that you think that these features are inconsequential and pointless, when we think they're essential and useful, is unsurprising. It's normal to think that the features in a language you know well are all essential, and that the features in a language you don't know well are all fluff. I'm sure I do it with other languages. If I may, I'd suggest checking out at least a couple of languages that come closer to the sort of dynamism that ObjC gives you, such as Python, Smalltalk, Ruby, Common Lisp's CLOS, and others. It may give you a better appreciation both for Objective-C and for how Cocoa is put together. Or it may just convince you that we're all crazy, it's hard to say. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
