Re: Renaming the "Cancel" button for NSOpenPanel
Re: Renaming the "Cancel" button for NSOpenPanel
- Subject: Re: Renaming the "Cancel" button for NSOpenPanel
- From: Severin Kurpiers <email@hidden>
- Date: Sun, 18 Mar 2007 06:28:58 +0100
Well, it's true, there were the comment "all instance variables are
private" in NSSavePanel.h from 10.2.8. This comment disappeared in
Panther and there are new ivars char _reserved[5] and void *_private
instead. I would rather expect that Apple is exposing variables that
can be exposed and hiding the private ones.
Yes, Google will find many pages containing the sentence "all
instance variables are private", but does it really mean that this a
general rule? A rule saying that there is no more need to declare
ivars @private or @protected, or at least to let the user know by a
comment that "all instance variables are private"? Apple is doing a
great effort to make things that have to be hidden opaque, so I would
rather expect that things publicly exposed are, well, publicly exposed.
Is there an official statement somewhere in the documentation that
I'm missing?
Bye,
Severin Kurpiers
On 17.03.2007, at 16:35, Uli Kusterer wrote:
Am 17.03.2007 um 15:05 schrieb Severin Kurpiers:
The variable _cancelButton is publicly exposed in NSSavePanel, the
super class of NSOpenPanel. I guess that it should be OK to use it
this way.
Wrong guess. Apple's official party line is that *all instance
variables are private*. In fact, if you Google for that sentence,
you'll find that NSSavePanel itself even used to have this as a
comment at the top. There's also evidence at Apple.com:
Several interesting Cocoa applications have implemented
dynamically-enabled document types, in which support for
additional document types is provided by plugins. Because
NSDocumentController and NSDocument access document type
declarations in Info.plist in a non-public way, developers have
resorted to accessing private NSDocumentController and NSDocument
instance variables directly, which is discouraged. To obviate such
discouraged behavior, new methods that you can override, in
addition to overriding existing methods, have been added so you
can safely implement your own dynamically-enabled document typing
scheme.
(from http://developer.apple.com/releasenotes/Cocoa/AppKit.html)
And at StepWise:
Apple informally reserves to itself the use of a leading
underscore character (_) when naming private methods and exported
functions. If developers were also to use this naming convention,
they would risk unknowingly overriding private methods in Apple's
frameworks, with unfortunate consequences. Apple also uses the
leading underscore for private instance variables, but the
compiler will probably catch instance variable naming conflicts in
your code.
(from http://www.stepwise.com/Articles/VermontRecipes/
introduction.html)
Apple *has* to declare its instance variables or the Objective C
runtime can't use them. But that doesn't mean you should use them.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden