Re: unique class name in Cocoa UI?
Re: unique class name in Cocoa UI?
- Subject: Re: unique class name in Cocoa UI?
- From: Hidetomo Katsura <email@hidden>
- Date: Tue, 26 Oct 2004 19:58:05 -0700
thanks! this information should be in WritingCocoaAUUIs.pdf. well, i
guess it's not AU plug-in specific but it applies to any piece of objc
code (e.g. plug-in) that runs in a shared context (e.g. host app).
so there is no scope, name space, or anything like that in objc so that
the host app can do something about it in the future? otherwise, it is
somewhat likely that there will be a conflict at some point unless we
all use class names like com_company_blah_blah_MyButton or whatever. is
there a such rule already in place and i just didn't know?
anyways, i have to change my class names now. thanks again! :)
katsura
On Oct 26, 2004, at 7:05 PM, john wrote:
Hi Brian,
Although your reply doesn't have anything to do with me, I just wanted
to say that I always appreciate your emails which contain great and
helpful information regarding Cocoa and ObjC. I enjoy reading them.
Thanks!
-- John
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
_______________________________________________
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
_______________________________________________
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