Trying this again, reply all this time... Jens, I think you’ve got the question backwards: the public ivar is in the base class, and the private one is in the subclass, and it works, even though they should both be in scope in the subclass’s implementation. I suppose it could be basically C-style variable shadowing at work here, though I’d expect to see a warning if that was the case.
Daniel On Jun 29, 2013, at 11:18 AM, Matt Neuburg <[email protected]> wrote: > > On Jun 29, 2013, at 10:55 AM, Jens Alfke <[email protected]> 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 = [email protected], 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 ([email protected]) > > 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/danhd123%40mac.com > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
