On Mon, Jun 9, 2008 at 7:02 PM, Chris Hanson <email@hidden> 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 (email@hidden)
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/email@hidden
This email sent to email@hidden
