• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Dynamic Languages [was: Re: why Obj-C]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic Languages [was: Re: why Obj-C]


  • Subject: Re: Dynamic Languages [was: Re: why Obj-C]
  • From: Dan Crevier <email@hidden>
  • Date: Fri, 05 Apr 2002 08:55:26 -0800

On 4/5/2002 7:23 AM, "Matthew Johnson" <email@hidden> wrote:

>> 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.
>
> Wow that9s 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.
>
> 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.

Someone will probably have a better answer, but here are a couple of
advantages:

* It solves the fragile base class problem. If you try to ship a C++ shared
library that others can use, as soon as you update it, all apps need to be
relinked since everything is pointer driven. With the message dispatching
in Objective-C, no such problem exists.

* It makes a lot of the functionality in IB possible. For example, you can
specify in IB to call a function basically by name when a button is clicked
or whatever. Of course, you get a runtime error instead of a compile time
error if you screw up. To do the same thing in with a C++ framework
requires having the interface builder generate code instead of just
resources, and that because a big mess when you also want to edit that code
and then go back and make UI changes.

* Some idioms like delegates rely on being able to query an object to see
what it can refer to. C++ soltuions, like PowerPlant's Lattachment aren't as
elegant.

Dan
_______________________________________________
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.

  • Follow-Ups:
    • Re: Dynamic Languages [was: Re: why Obj-C]
      • From: Matthew Johnson <email@hidden>
References: 
 >Re: Dynamic Languages [was: Re: why Obj-C] (From: Matthew Johnson <email@hidden>)

  • Prev by Date: Re: Apple Events and CFRunLoop?
  • Next by Date: Re: Apple Events and CFRunLoop?
  • Previous by thread: Re: Dynamic Languages [was: Re: why Obj-C]
  • Next by thread: Re: Dynamic Languages [was: Re: why Obj-C]
  • Index(es):
    • Date
    • Thread