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: Donald Brown <email@hidden>
- Date: Fri, 05 Apr 2002 09:44:20 -0600
There's a system object, NSTextView. I want to add a call to it,
"-(void)parseURLS". I could subclass NSTextView, but instead, I can create
a category (call it URLParser) and add parseURLS to all NSTextViews in my
project.
Also, the FirstResponder and Menu interaction is a great use of this. The
"Cut" menu is connected to FirstResponder's "cut:" selector. When you click
on the menu bar, the application kit asks the first responder "Do you have a
selector 'cut'?" If it does, the menu item is enabled. If not, it is
disabled. The user picks Cut, and the menu item calls cut. Doesn't matter
what that first responder is, all that's necessary is to set up what
selectors you respond to. (It's possible to have finer control over menu
item validation, but not necessary.)
Donald
on 4/5/02 9:23 AM, Matthew Johnson at 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.
>
>
Matt
>
_______________________________________________
>
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.
--
Donald Brown
email@hidden
http://www.eamontales.com
We have met the enemy and he is us - Pogo
_______________________________________________
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.