Re: unique class name in Cocoa UI?
Re: unique class name in Cocoa UI?
- Subject: Re: unique class name in Cocoa UI?
- From: Brian Willoughby <email@hidden>
- Date: Tue, 26 Oct 2004 18:45:50 -0700
With Objective C, the standard recommended practice is to prefix your class
names with your company (or personal) initials. My library classes start with
"SC" for "Sound Consulting," and you'll see many classes which begin with "NS"
for NextStep. You probably should never send code out the door with classes
that start with "My" because that's just going to potentially conflict with
lots of sample code and beginner programmer projects.
By the way, ObjC does not exactly look up the class names with each message
dispatch. The runtime information in cached so that it is much faster than an
exhaustive lookup. However, when each bundle containing ObjC classes is loaded
into a particular application, that application's method dispatch cache is
rebuilt by the runtime to reflect the new classes that have appeared. In this
case, when each AU is loaded for the first time (the AU being a type of
bundle), the ObjC classes in its Cocoa UI are processed by the ObjC runtime.
The error message you see below is a warning that a conflict in class names was
detected, and it is being managed by only using one of the classes.
Another way to look at this is: Do you really need a custom Button class?
Typically, newcomers to Objective C tend towards the C++ approach of
subclassing everything. ObjC allows for delegate, target-action, and other
paradigms of programming that reduce the need for subclassing. The best way to
avoid a conflict in class names is to learn how to better use the Button class
to get done what you need.
Even if you still need a custom Button subclass, perhaps that could be made
into a Framework that all Cocoa UI AudioUnits use. Once MyButton is in a
Framework (hopefully, with a better name than "MyButton"), it will only be
loaded once. This saves on RAM usage when a Host loads many AUs with custom
Cocoa UI (not exactly a common problem yet, but we may eventually have lots of
Cocoa UI). The benefit of a shared Cocoa UI Framework for AUs is that as bugs
are fixed in the custom UI classes, all AUs using the Framework would
automatically benefit from the bug fixes even without being recompiled. All
your users need to do is install the fixed Framework (Frameworks also have
extensive versioning which can allow multiple versions of a Framework to exist
on the same machine for backwards compatibility).
Sorry this got so long, but there is a lot to cover now that Cocoa UI are
starting to become popular.
Brian Willoughby
Sound Consulting
Begin forwarded message:
From: Robert Grant <email@hidden>
Subject: Re: unique class name in Cocoa UI?
I think you've hit on the problem. Obj-C uses a runtime look up scheme
for message dispatching and it'll use the first implementation of
MyButton it finds. If the two classes do two different things - give
them two different names! :-)
Robert.
On Oct 26, 2004, at 9:04 PM, Hidetomo Katsura wrote:
> could someone tell me if this is expected and i just need to
> workaround it by using a unique class name for each plug-in? or is
> there a simple way to avoid it?
>
> i get the following console log when i edit parameters of my two Cocoa
> UI AU plug-ins which use the same obj-c class name, "MyButton." each
> plug-in has a different implementation of MyButton class (it probably
> shouldn't but it does).
>
> "HostApp.app: objc: Both CocoaUI_1 and CocoaUI_2 have implementations
> of class MyButton"
> "HostApp.app: objc: Using implementation from CocoaUI_1."
> "HostApp[pid] *** -[MyButton myMethod:]: selector not recognized"
>
> isn't the host app supposed to use the class in the Cocoa UI specified
> by the plug-in? or is it simply not possible?
>
> thanks in advance,
> katsura
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden