Re: audio-specific UI component libraries for Cocoa?
Re: audio-specific UI component libraries for Cocoa?
- Subject: Re: audio-specific UI component libraries for Cocoa?
- From: Brian Willoughby <email@hidden>
- Date: Mon, 1 Nov 2010 18:11:03 -0700
On Nov 1, 2010, at 18:00, Kevin Dixon wrote:
I'm not sure I understand the Cocoa namespace problem very well. Does
this mean that even if the controls are distributed as just .h/.m
files to include in your project, the names could conflict if multiple
plugins simply have the same class name? Maybe I'm not remembering
correctly, but we *do not* have this problem in C and C++, correct?
This seems a bizarre design choice.
ObjC classes are dynamically loaded and merged within an application
to a global namespace. This can be a powerful feature when using
categories, but it is as dangerous as it is powerful. In any case,
the long-standing Cocoa convention is to prefix all of your custom
class and subclass names with your 4-char identifier to avoid
collisions with other developers in a plugin environment. I believe
that it's even common when developing Frameworks in a non-plugin
environment.
C and C++ have the same problem if you don't use namespaces, but
namespaces are enabled by default in Xcode so nobody ever sees the
problem with C and C++ unless they're working on an esoteric
project. I can't remember when the transition was made, but there
was a point in OSX history when this feature of the compiler was NOT
enabled by default.
As some of my younger programmer associates say: "I'm glad I live in
the future!"
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