Re: unique class name in Cocoa UI?
Re: unique class name in Cocoa UI?
- Subject: Re: unique class name in Cocoa UI?
- From: john <email@hidden>
- Date: Tue, 26 Oct 2004 22:05:37 -0400
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