Re: Name instance variables, methods and parameters.
Re: Name instance variables, methods and parameters.
- Subject: Re: Name instance variables, methods and parameters.
- From: Public Look <email@hidden>
- Date: Sat, 31 Jan 2004 10:24:15 -0500
On Jan 31, 2004, at 5:19 AM, Dietmar Planitzer wrote:
On Jan 28, 2004, at 4:00 AM, Czarny, Eric wrote:
There are two different problems here which we should keep separated:
1) Prefixing your own instance variables with an '_':
You can do this without having to fear any negative consequences.
Contrary to methods, every subclass-able class must declare all of its
instance variables in the interface block. The technical reason for
this requirement is that the compiler must be able to compute the size
of a class instance so that it can correctly create and fill out a
class structure for the runtime and because the compiler must be able
to compute the variable offsets which are needed for the load/store
machine instructions.
If you ever happen to pick a variable name for one of your instance
variables which is already in use by one of the super classes of your
class, then the compiler will abort compilation with a 'duplicate
name' error. So there is no way that you could overlook a name clash.
There is still a problem! Apple may change the name of an instance
variable declared in a header between releases and inadvertently break
your code that compiled and worked with the previous version. This
happens in part because Apple places "reserved" instance variables in
base classes as a hedge against Objective-C's weaker form of the
fragile base class problem. Someday it may be used instead of just
reserved. You won't overlook a name class, you will just get mad that
your source code no longer compiles on a new release.
I personally have been prefixing my instance variables with an
underscore for the past 7 years and have never run into a single name
clash. And even if I had, it wouldn't have been a problem because the
compiler would have told me so. Thus, I can't really follow the logic
of Apple's documentation in this case.
The simple solution is for third parties to use an underscore AND a
unique prefix.
2) Prefixing your own methods with an '_':
Here the situation is more problematic. The real fundamental problem
is that ObjC does not require that every method be declared in the
interface block of a class and that it does not support access control
for methods. Thus, private methods are commonly not declared in the
public interface block of a class which also means that the compiler
is no longer able to detect method name clashes which involve such
private methods.
Because of this and because Apple has chosen to use the underscore to
mark its private methods, you should not prefix your own private
methods with an underscore. However, in actual practice things are not
as easy and clear cut. There are a number of Cocoa classes which do
have private methods that don't start with an underscore. I.e. NSView
has a private method called invalidate: which does not start with an
underscore. There's also a compareGeometry: method which again does
not start with an underscore.
Ergo, not prefixing your method names with an underscore still does
not give you any guarantee that you won't collide with a private
framework method of one of your class' super classes. In my opinion,
it would be better if ObjC would explicitly deal with this problem on
the language level. I don't like it if languages try to solve language
problems purely by unenforceable conventions. Because human being are
supposed to follow those conventions and they make mistakes.
At least Apple should have chosen another prefix for its own private
methods like __apple_ and they should have left the simple to use
prefix to us poor little third-party developers...
It is part of the greatness of Objective-C that you can send any
message to any receiver. The possibility of sending messages that
invoke "private" methods is an unavoidable consequence, and in some
ways it is a great capability. I have often been frustrated by
frameworks in some other languages that declared a member function
private: instead of protected: meaning that I can't call the member
function even from my subclass. I personally don't think private
methods have much utility over protected methods... Finally, other
languages give you no real protection either. There is always #define
private: public:. he private: designation is just an indication of the
designers expected usage. Hmmmm, not documenting a method in a header
file is just an indication of the designers expected usage.
Agian, the simple solution is for third parties to use an underscore
AND a unique prefix for "private" methods.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.