On Mon, Jun 9, 2008 at 7:02 PM, Chris Hanson <[EMAIL PROTECTED]> wrote:
> The reason these kinds of methods have a return type of (id) is that there > is no way to say "returns an object of the receiver's class." For example, > +[NSArray array] returns (id) rather than (NSArray *) because otherwise > +[NSMutableArray array] would require a separate declaration (NSMutableArray > *). Rather than have a large number of separate declarations, these methods > return (id). If this is true, it rather contradicts your point, because it should be perfectly legal to return an NSMutableArray (a subclass of NSArray) from +(NSArray *)array. Notwithstanding, you are right that John seems to be mistaken about polymorphism. John, perhaps it would help you to think of 'id' as being the type of an abstract superclass to NSObject? (Yes, I know from previous discussions that 'id' is actually a typedef of a struct, etc. Let's not revisit that!) If I ever claimed that the GC's behaviour is wrong, let me rescind that: it was based on my conflation of "the stack" and "the current scope". However, I do still think that a whole class of bugs could easily be avoided by having the compiler ensure that pointer variables remain on the stack whilst they are in scope, and I'm not convinced that the cost of the extra pointer copy and stack slot this would require is such a terrible a price to pay. 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]
