On May 26, 2010, at 6:10 AM, vincent habchi wrote: > So, tell me if I'm wrong, but I infer from your answer that whatever I can > do, there is no means for a subclass A' to access any private variable of its > ancestor.
Not without some nasty tricks (this is native code, so nasty tricks are always possible.) I think you’re confusing an inaccessible variable with an unused variable. Those are very different concepts. For example, NSView’s _frame instance variable is inaccessible from any subclass, but the variable is of course a crucial part of the view’s state and is accessed by lots of methods in NSView itself. > Well, as a regular Python code writer, I've never missed @private (or even > @protected) declarations. Actually the lack of encapsulation in Python is one reason I gave it up in favor of Ruby. An class’s instance variables are implementation details and shouldn’t be exposed to its clients, or it becomes difficult or impossible to re-implement the class differently in the future. This is not always important in small projects, but it becomes more and more important as the number of people working on the code grows, and it’s crucial for creating solid library APIs. > I fail anyhow to grasp the relevancy of @private vis-à-vis @protected: It > seems logical to me that subclasses be granted access to all ancestor > attributes. A subclass is just a special kind of client. The contract between a base class and its subclasses is a type of API and also needs to be controlled. Otherwise you can’t change the implementation of the superclass without breaking subclasses. For example, if every 3rd party app’s custom views could access the internal state of NSView, it would give the AppKit team fits any time they tried to re-architect the view system (as they’ve done several times since 10.0 shipped.) —Jens_______________________________________________ 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 arch...@mail-archive.com
