Re: Calling the same function in multiple classes
Re: Calling the same function in multiple classes
- Subject: Re: Calling the same function in multiple classes
- From: Bill Cheeseman <email@hidden>
- Date: Tue, 05 Nov 2002 07:29:41 -0500
on 02-11-05 12:28 AM, Andrew Merenbach at email@hidden wrote:
>
It looks convoluted, but runs well. Is there any particular
>
reason--other than the obvious "it's convoluted!"--not to use it? Most
>
notably, will I most definitely *not* have a speed improvement with the
>
second method? Or is it even poor coding?
It strikes me that you're unnecessarily duplicating the Objective-C runtime
engine's work.
The runtime resolves an Objective-C message by selecting which object should
receive the selector at run time. That's why the one is called a "receiver"
and, more to the point, why the other is called a "selector", and it's the
main reason why Objective-C needs a runtime. The Objective-C runtime figures
out which class's version of the identically-named selector to execute, by
looking at the type (class) of the actual receiver at run time. The type
(and identity) of the actual receiver may not be determined until run time
(if you specify it as type "id", for example). This is why Objective-C is
called a "dynamic" language; symbols are "late bound". This is at the center
of what makes Objective-C such a powerful and flexible language.
It's also the main reason why the Cocoa frameworks are so cool. You see many
examples of this throughout the Cocoa frameworks, where an identical method
name is reused in a number of different, apparently unrelated, classes. Yet
the right method is executed even though you don't always tell your
application the class of the receiver at compile time.
So you should be able to have your multiple XXXController classes, each with
an identically-named "showView" method, then just send a message like this:
[myController showView]. You shouldn't need a switch statement or an array
of shared instances to pick the particular class to handle the message at
compile time, because the Objective-C runtime will do that for you at run
time.
You shouldn't have to do anything special to implement this. Just call
[myController showview] and see if it works. The runtime is highly optimized
to make message resolution very, very fast. It is undoubtedly much faster
than your switch statement or array selector.
By "myController", I mean an object that might be typed as any one of your
XXXController classes depending on the circumstances under which it is
called at run time. For example, you might have a pop-up menu allowing your
user to choose the view to be shown. The action method for the pop-up menu
should only have to send a [chosenView showView] message, not a specific
strongly-typed message that your code selects explicitly by using the switch
statement or array selector you have written.
I think you just need to wrap your mind around the basic nature of
Objective-C as a dynamic lanugage.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
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.