Re: ObjC Method naming
Re: ObjC Method naming
- Subject: Re: ObjC Method naming
- From: "David W. Halliday" <email@hidden>
- Date: Mon, 28 May 2001 15:01:51 -0500
- Organization: Latin AmeriCom, formerly Latino Online
Pedrum Mohageri wrote:
>
I have a silly question about the style convention used in Objective C
>
code. Take this example from page 56 of the ObjC reference.
>
>
[myRect setWidth:10.0 height:15.0];
>
>
Does this mean there is a method called set with two parameters width and
>
height? Wouldn't that be represented like this:
>
>
[myRect set Width:10.0 height:15.0];
>
>
Or does it mean there a method called setWidth with two parameters, a
>
nameless one(default?) and height.
>
>
I am coming from C/Java background so all these brackets and colons are
>
throwing me off a lot. ;-)
I have found there are at least two or three issues involved here,
especially for those coming from a Java or C++ background (though one of the
issues has no bearing on C++, at this time).
1) What is the nature of method names within Objective-C?
2) What are the naming conventions used by programmers in general, and the
Cocoa APIs in particular?
3) How are the Objective C names in the Cocoa APIs mapped to Java names?
(This is the one that has no relevance to C++, at this time, since their is no
attempt to map the Objective-C object model into the C++ object model---their
too different.)
Unfortunately, I don't have a definite algorithm for problem 3. It is
dependent upon the mapping conventions of the Java bridge, and other issues
that I haven't decided to delve into.
As for question 1: The example you give of "[myRect setWidth:10.0
height:15.0];" is interpreted, within Objective-C, as passing a message to the
object "myRect", with a method name of "setWidth:height:", and two parameters
"10.0" and "15.0". This is also the SmallTalk way of interpreting such a
method call. (Objective-C is kind of a compiled SmallTalk like language built
atop C. It may actually help you to read some on SmallTalk.) Furthermore,
though there is a tendency to use a key/value naming convention, especially
within the Cocoa APIs (in partial answer to question 2), such is not at all
required by the language. (Some mistakenly interpret this as some form of
named parameter passing---another misconception based upon a naming
convention.)
The general rule of thumb, when it comes to method naming, is to try and
make method calls as human readable, or self documenting as possible
(unfortunately, sometimes, human readable vs. self documenting conflict).
Therefore, one may desire that the method name be such that a method call
reads as a sentence or phrase (though I find that much of the Cocoa APIs tend
to have the arguments read as sub-phrases, set off by the colons, thus giving
a name/value feel).
As for question 2: The flexibility of method names is such that it often
helps to have a naming convention, just as with most any programming language,
these days. Back when NeXT developed OpenStep (an open specification for the
NeXTstep APIs), NeXT cleaned up the APIs and specified a general naming
convention (though I'm sure it can be argued as to whether they were entirely
consistent in their use of the stated convention).
At one point, I had a fairly intuitive feel for the naming convention,
which helped in navigating the APIs, but, alas, I haven't been steeped within
this programming environment enough of late (too long an absence doing Java
programming, I'm afraid), so I've lost some of that feel. Even then, however,
I couldn't tell you, off the top of my head, what the formal naming convention
was, so I certainly cannot now. (In fact, I don't know that Apple even has
one, or how well they adhere to any they might have.)
(Incidentally, method forwarding does provide some benefit to using a
key/value naming convention, in that implementing such forwarding, at least
when using dictionaries, is easy to map, in general, when using such a
scheme. The influence of this can be seen very strongly in the Objective-C
implementation of WebObjects and EOF.)
So, even though I cannot answer all the questions I've presented, I do
hope I've helps in some small way.
David email@hidden