On Wed, Jun 11, 2008 at 8:01 AM, John Engelhart <[EMAIL PROTECTED]> wrote:
> A return type of NSArray * means something very explicit. "But all you can > expect is an object that behaves like a NSArray, so returning a subclass of > NSArray, like NSMutableArray, is perfectly legal!" You're exactly right > that all I can expect is an object that behave like a NSArray. /Exactly/ > like a NSArray. Not sorta. Not almost. Exactly. Because that's what you > explicitly stated. What you seem to be arguing for here is a different design of the NeXTstep classes. You want an abstract base class, NSArray, with children NSMutableArray and NSImmutableArray. Then, if you want to design a class to return an immutable array, you use NSImmutableArray, and there is no room for confusion. The designers of the NeXTstep classes presumably noticed that NSImmutableArray wouldn't add any extra methods to NSArray, and decided to design it the way they did. You could, if you wished, force the issue in your own code by declaring a class NSImmutableArray yourself. However, this doesn't change the fact that, as the class heirarchy stands, an NSMutableArray is an NSArray. This is a basic tenet of polymorphism in object-oriented programming. If, from an interface declaring (NSArray *) as its return type, you get an NSMutableArray, don't worry -- just don't mutate it. If some other part of the framework mutates it, this is no more correct behaviour than if it had returned an immutable array and then overwritten some of its storage directly in memory. Hamish _______________________________________________ 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]
