Re: Dynamic Languages [was: Re: why Obj-C]
Re: Dynamic Languages [was: Re: why Obj-C]
- Subject: Re: Dynamic Languages [was: Re: why Obj-C]
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 8 Apr 2002 18:15:22 -0400
On Friday, April 5, 2002, at 10:23 AM, Matthew Johnson wrote:
[...description of what 'dynamic dispatch' means deleted ...]
Wow thats a fantastic explanation! Thank you very much. This explains a
lot. I.e why a program will compile and run and then spits the dummy when
you invoke a method that is not in the class.
Thank you.
It sounds like you aren't taking full advantage of the compiler's ability
to validate method calls.
First, don't declare an object reference as type (id). Instead, declare
it to be a reference to the most specific possible class you can. I.e.:
NSMutableArray *activeCells;
NSView *drawingTarget;
For instance variables that will be connected in IB, do:
IBOutlet NSView *outView;
(IBOutlet is #defined to nothing -- IB uses it to parse the subsequent
variable declaration as an outlet definition)
When compiling, your code should generate ZERO warnings. If you see a
warning such as 'Objects of class Foo do not respond to message
-foo:bar:baz:', it very likely indicates a problem that will cause the app
to 'spit the dummy' (nice expression, but what does it mean? :-) at
runtime!
If you use deferred execution functionality-- i.e.
-performSelector:afterDelay:, the array method to perform a selector on
each contained object, NSUndo API, objc_msgSend() directly, etc... -- you
can still cause the app to toss an 'object does not implement' exception.
There is one particularly nasty situation in which you can see the 'object
does not recognize selector' error at runtime that can be very hard to
debug. Specifically, if you have a retain/release problem such that a
reference to an object has been released completely AND the memory
originally held by that object just so happens to be filled with an object
of some other class, you can see the 'object does not recognize selector'
error in some very odd circumstances. This happens rarely, thankfully,
and is fallout from using a pointer based language (C++ and C have similar
failure modes, but tend to be more catastrophic in the pattern of failure)
.
Alright now I understand that my next question is what is the inherent
benefit of doing this? I can't see it. In fact I can only see the downside
of doing it that way. I.e it compiles.
One benefit I can see is with shared objects introducing new features to
a
executable without the need for recompiles. But I can reproduce this in
straight C.
I believe this has mostly been covered by others. I would add that it
allows for a certain level of abstract design that is very difficult to
achieve in functional languages or static OO languages. Delegation is a
prime example. An NSWindow instance can have a delegate that can
implement any of a number of methods to customize the behavior of the
NSWindow. In a static OO environment, that would typically involve a
subclass which would lead to a lot of complexity in that instances of the
subclass have to be bound back to the Model/Control layer.
Delegation adds a very natural means via which View layer objects (such as
NSWindow) can query into the Model layer in a somewhat casual manner to
determine if the behavior should be modified in some fashion. It is
merely a case of the NSWindow asking its delegate if it responds to a
particular selector and invoking it, if it does.
Certainly, this could be done via straight C using callbacks, but that
would lose the whole OO pattern entirely.
The undo functionality provided within Cocoa is another example. By
allowing a method invocation and its parameters to be encapsulated into an
object, it allows for an extremely elegant solution to implementing an
infinitely deep undo solution.
Finally, I don't think anyone mentioned this: The dynamic runtime /
dynamic method dispatch model makes it [relatively] trivial to integrate
Objective-C with other languages such as Python, Perl, Ruby, AppleScript,
or Java (all of which have bridges of some kind or another).
b.bum
Do the voices in my head bother you?
_______________________________________________
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.