Re: Cocoa-dev Digest, Vol 5, Issue 919
Re: Cocoa-dev Digest, Vol 5, Issue 919
- Subject: Re: Cocoa-dev Digest, Vol 5, Issue 919
- From: "Kyle Sluder" <email@hidden>
- Date: Tue, 27 May 2008 01:47:52 -0400
On Tue, May 27, 2008 at 12:33 AM, Johnny Lundy <email@hidden> wrote:
> There is a receiver. Yet the receiver is never listed in any of the method
> descriptions.
There is no "one receiver". Instance methods are defined on ANY
object of the type for which the documentation you're reading
describes. For example, the documentation for -description in the
NSObject reference is valid for any object of type NSObject (or a
descendant type). How is the documentation supposed to describe "the
receiver" when ANY Objective-C object will respond to this message?
Now, this came up in the context of NSWorkspace, which is treated as a
singleton, so in *this specific instance*, there's really only one
valid receiver. But the question shouldn't be "what's the receiver
for this method?" (answer: an NSWorkspace instance) but rather, "how
do I get an NSWorkspace instance?" And this question is explicitly
answered for you by pointing at the documentation for +[NSWorkspace
sharedWorkspace].
By the way, to reiterate what is explained in very fine detail in the
introductory manual to the language, there are a few conventions used
in describing Objective-C methods:
1) "foo:bar:" is a selector.
2) "-foo:bar:" is an instance method. This form is used when either
the type of the receiver is unimportant or is obvious from context.
3) "+foo:bar:" is a class method. This form, like the one above, is
used when the type of the receiver is obvious.
4) "-[Class foo:bar:]" is the form of (2) used to make the class of
instances matters.
5) "+[Class foo:bar:]", likewise, is the explicit form of (3). Note
that when using class methods, you'll actually write something like
"[Class foo:bar:]", whereas instance methods are invoked on instances
of a class, and so will be something like "[id foo:bar:]".
6) "-(type)foo:(type) bar:(type)" is a method signature for an
instance method. This is the form used to declare methods (albeit
with argument names), and is rarely used in print except to argument
or return types.
7) "+(type)foo:(type) bar:(type)" is the class version of (6).
If *any* of the terms used in the above definitions are unknown to
you, you cannot consider yourself knowledgeable enough about the
Objective-C language to learn Cocoa properly.
> That's not true, and the tone of that is a holdover from the early days of
> the USENET groups where it was considered appropriate to chastise newbies,
> AOLers, etc. I can take it because I was around back in those days and know
> where it comes from -- but it is surely scaring away many people who would
> want to post.
Do you honestly believe that with your failure to understand basic,
fundamental concepts *of the language*, a fault entirely of your own
doing for lack of reading and comprehending the documentation, gives
you the right to so vociferously criticize the organization and
quality of the *Cocoa framework* documentation?
You spend so much energy laying blame at the feet of the technical
publications staff for perceived shortcomings in their work, yet
reveal that you don't even know the language that the framework is
written in, thus revealing the source of your inordinate difficulties.
I do hope you're still reading, because I strongly urge you, before
you put finger to keyboard in reply to this or any other message
rebutting your arguments, to actually sit down and assess your
knowledge and position in contrast to the heavy accusations of
ineptitude you have leveled at the techpubs staff.
I do not wish to see you remain in this state of denial. Perhaps you
are ignorant of what it is that you do not yet grasp. I hope that you
understand these three things and properly address your shortcomings
before continuing:
1) This mailing list deals with Cocoa. This is not an Objective-C
correspondence course. Nor is it a paint-by-numbers consulting
service, for those who continue to ask questions like "How do I write
a program with this list of features?"
2) You do not know the Objective-C language. This is separate from
knowing Cocoa, which involves understanding its use of certain
patterns and conventions. You don't know the language, which leads to
disconnects such as attempting to identify "the receiver" of a given
method, and the ensuing frustration when such information is not
document because it doesn't exist.
3) Ample documentation exists describing the language that is
separate, yet exists alongside, the framework documentation. I have
linked to it previously. I urge you to read it, practice it, write
programs with it, research it, explore it. Even if it means sitting
down with a printout of the PDF for a few hours and then writing some
code. And while you don't really need Cocoa to learn Objective-C, a
bit of time learning some of the basics of the language will make the
documentation palatable enough to use when you attempt to write
programs that, for example, write stuff to the console.
All in all, step 3 is not really that hard or laborious. Assuming
competence in another OOP language, I estimate that any given
programmer can understand and internalize the Objective-C methodology
in about a week or two. And then about a month of practice before
simple Cocoa programs come naturally. Six weeks is the length of some
certification courses in tiny facets of certain frameworks. Six weeks
to learn a language that is quite a bit different from the more
popular C++, Java, and C# *and* the beginnings of a powerful framework
is not too shabby.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden