Dynamic Languages [was: Re: why Obj-C]
Dynamic Languages [was: Re: why Obj-C]
- Subject: Dynamic Languages [was: Re: why Obj-C]
- From: Bill Bumgarner <email@hidden>
- Date: Fri, 5 Apr 2002 09:49:24 -0500
(As usual, what started out as a relatively hot topic that had a series of
excellent posts has degenerated into a bit of a flame fest. Gotta love
the net. I changed the subject to be more reflective of this particular
subject.)
Aha! Therein lies the problem. Your experience has been drawn from
languages that are primarily statically bound (lisp being the exception)
whereas Cocoa, Foundation, and IB are all heavily reliant upon a fully
dynamic OO model.
ObjC is much more akin to Python, Dylan, or SmallTalk. It is a combination
of ANSI-C, a small quantity of syntax to add OO features, and a dynamic
runtime. The dynamic runtime is the part that is likely the largest
source of confusion-- none of the languages in your list have a dynamic
runtime.
By 'dynamic runtime', I mean that-- at runtime-- messages to objects are
resolved dynamically. I.e. if I say...
[someObject performClick: nil];
.... which is 100% functionally equivalent to this ....
objc_msgSend(someObject, @selector(performClick:), nil);
... then the Objective-C runtime figures out how to dispatch the message.
That the above are equivalent should help drive this concept home-- if a
method invocation is really just a call to a C function that takes the
pointer to the target object and finds the method implementation on that
object all means that method dispatch occurs entirely at runtime.
Objective-C also has some static features. Namely, the compiler is
smart enough to know that if a pointer to an object is defined to be, say,
a pointer to an instance of NSView (or subclass) and the developer has
invoked a method that is not defined on NSView (or any of its superclasses)
, then the compiler will emit a warning-- not an error, but a warning
(since any good body of code should compile without warnings, the presence
of a warning is like an error to most developers).
Similarly, method dispatch using the [target method: anArg] syntax is
highly optimized. If you look at the objc runtime source in Darwin, you'
ll see that method dispatch breaks down into a relatively short and
throughly imponderable hunk of assembly (Actually, Matthew could probably
grok the assembly with his background with mc68000 assembly).
In C++ and, to a lesser degree Java, a method invocation is very much
like the syntax implies...
someObject.performClick(NULL);
... grab the function pointed to be the performClick() member of the
someObject structure and call it. Do all this at compile time and emit
highly optimized code that says to do exactly that when executed under the
assumption that someObject will always point to a structure where the
performClick() member is always in exactly the same spot within the
structure. I.e. it isn't dynamic, not in the least.
(Java varies in that the virtual machine implies a slightly less
pointer centric approach to all of this.)
Once your grok this, that lays the foundation for understanding the
design patterns used throughout the Foundation and Cocoa. The worst
mistake anyone can make when trying to learn Cocoa is to assume that it
works like Carbon, the AWT, the X Windows API, etc... It simply doesn't
and trying to treat it as such is going to be extremely frustrating and
unproductive.
Finally, a mantra that has helped me many times over the 10+ years
that I have been working with the Cocoa APIs [i.e. OpenStep, NextStep, etc.
..] has been this:
There Is No Magic.
If I feel like the frameworks are behaving in some magical fashion or
if I feel like the APIs are fighting my every effort to implement a
particular feature, it is time to step back, repeat the mantra, and
reexamine the documentation and APIs. In just about every case, it
proves true that I missed some bit of documentation or API or
misunderstood some particular design pattern and was quite effectively
making my code and development experience a whole heck of a lot more
complex and tedious than it needed to be.
I would highly recommend grabbing Aaron Hillegas's wonderful Cocoa
Programming book and going through the exercises.
b.bum
On Friday, April 5, 2002, at 01:09 AM, Matthew wrote:
In order of learning (oldest to youngest):
FORTRAN,basic,Pascal,lisp,prolog,C++,C,X86 assembly,mc68000 assembly,Java
In order of preference:
C,C++,Java,FORTRAN,Pascal,basic,lisp,prolog,mc68000 assembly,X86 assembly
I disagree, The more languages I have under my belt the less expert I
become in the lot. Maybe I am getting old and
feeble but I seem to of reached a limit in which if I learn something new
I forget something old ;)
_______________________________________________
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.