• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Name instance variables, methods and parameters.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.
References: 
 >Name instance variables, methods and parameters. (From: "Czarny, Eric" <email@hidden>)
 >Re: Name instance variables, methods and parameters. (From: Dietmar Planitzer <email@hidden>)

  • Prev by Date: Finder plugin in Cocoa
  • Next by Date: Re: compiling sqlite
  • Previous by thread: Re: Name instance variables, methods and parameters.
  • Next by thread: Re: Name instance variables, methods and parameters.
  • Index(es):
    • Date
    • Thread