On Jun 29, 2013, at 10:55 AM, Jens Alfke <j...@mooseyard.com> wrote:
> This is just a parsing issue. If an ivar is declared in a class’s public > interface, it’s in scope in any method of that class or a subclass. So if a > subclass declares an ivar with the same name, you now have a conflict and the > parser won't know which one you’re referring to, so it won’t let you do that. > That is what I would have thought, but that is exactly what I appear to be doing. That's what I'm finding so odd. * MyClass, the superclass, defines "thing" as an int, in public (in its interface section in its header file). * MyClass2, the subclass, defines "thing" as an NSString*, in private (in its implementation section). I would have expected a conflict. Instead, the compiler seems quite happy, provided any mention of self->thing in MyClass2 is an NSString. Of course it's possible that I've just confused the heck out of myself and my experiment doesn't show what I think it shows. But try it; I think you'll find that what I'm saying is true. m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
