On Jun 29, 2013, at 7:48 PM, David Duncan <david.dun...@apple.com> wrote:
> On Jun 29, 2013, at 11:18 AM, Matt Neuburg <m...@tidbits.com> wrote: > >> >> 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. > > > Think of it like scope. Your class's @implementation defines a more limited > scope than the class's @interface or its superclass's @interface. When you > add a new ivar in the @implementation block, it hides the ivar from the super > class, just as what happens when you define a local variable with the same > name as an enclosing scope. > > What can get confusing is that if you type case to the super class you can > still access the hidden ivar. In general I would avoid this (as I would avoid > declaring ivars in a public interface). Fascinating, Captain! I really like this "scope" analogy. In my defence, I was declaring the ivar in the public interface only because I wanted to experiment with the subclass's access to the ivar; it can't see the ivar at all if it isn't declared in the superclass's public interface (or in a mutually imported header file, which is what I usually do in these situations). I hadn't gotten around to trying the typecasting trick yet. :))) Thx as usual - 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
