Re: Guidance for Cocoa's steep learning curve

FROM : David Wilson
DATE : Thu May 15 07:16:04 2008

On Wed, May 14, 2008 at 11:33 PM, Scott Ribe <<email_removed>> wrote:
>>> === If you are primarily an experienced C++ programmer (In my
>>> experience you will have the hardest time)

>>
>>
>> (2) I will have to personally disagree with this.

>
> I wonder, seriously, if it doesn't depend somewhat on whether or not you're
> a really good C++ programmer...
>


I'd say it depends more on the type of C++ programming you're coming
from. If you're coming from a purely procedural background with no
event-driven experience, some pretty fundamental Coca concepts are
going to be problematic. If you're comfortable with C++ strict typing
rules, Objective-C may appear to have too much runtime magic going on.
On the other hand, if you've spent a lot of time abusing void * to
hack runtime dynamism into C++, Objective-C will be a breath of fresh
air ("You mean I can do this with sane syntax rather than lots of
casts and abuses of types?"). Also, memory management may throw you
for a loop if you haven't seen reference counting before; if you've
implemented it in C++ out of frustration, however, it's quite clear.

When I was first learning Cocoa and Objective-C, coming from more of a
systems programming background, what made sense of it was to
understand the runtime itself- and there is documentation on it- so
that things ceased to be "black boxes" and I could trace program
control flow without gaps. Once it's clear that methods are just
virtual functions with a different syntax and the ability to actually
determine whether or not they exist at runtime rather than crash,
objective-c is identical to c++ object oriented programming (okay, for
loose definitions of "identical", I don't want to get into the
details; given that insight there are clear broad similarities in
implementation).

So, from a C++ perspective, I'd offer the following points:

1) The type "id" is just void *, except the compiler doesn't complain
when you don't cast it to something real before calling functions on
it as an object.
2) Method calls are just calls to virtual functions, with a little
more runtime support to make them less fragile. In effect,
*everything* in Objective-C is a virtual function; you can't have
non-virtual functions.
3) Instance methods (with the -) are virtual functions. Class methods
(with the +) are static functions.
4) Outlets are just pointers. When your nib gets instantiated with
your object as File's Owner, your outlets (just member variable
pointers) have their values set to point to the things you told them
to point to in the nib.
5) Target-Action setup is just a pointer to an object + a function
pointer. You're telling something "Hey, when X happens, call this
function on this object." Think of callback functions.

There are others, but those are the most basic. Once you can map the
Objective-C constructs onto what's happening under the hood, it
becomes more clear how to take advantage of them.

--
- David T. Wilson
david.t.<email_removed>