I may be misunderstanding something with how bundle loading in general works, or perhaps stumbled on a bug in QC, or not understand something subtle about the Obj-C runtime.
Loading QC, making a new composition and instantiating Plugin B shows me logging does not work. Quitting Quartz Composer, manually removing Plugin A, relaunching, now logging from Plugin B works.This means plugins can effect one another's ability to function? Am I misunderstanding something about bundles? Is this a legitimate bug?
Effect one another's functionality: YES Misunderstanding something about bundles: NO (er, not really) Legitimate Bug: NOExplanation: This has nothing (well, trivially nothing) to do with bundles, and a ton to do with the objective-C runtime in Leopard (and Tiger) -- When loading a bundle that defines Class A, any pre-existing classes named Class A get blasted away by the newest loaded version. This is true in every application, not just QC (and it's also how we work much of our magic with our plugins ;)
Since the load-order of plugins isn't defined, you really really really don't want to dpend on this (and if the runtime behaviour changes in the future, you're dead).
How should one go-about adding re-usable classes to bundles to provide functionality, but keep those classes private (assuming we want our plug-ins to be able to subclass and still reference ivars from the superclass - using @private would kill this funcionality, no?). Would having a framework be a solution? Im still concerned however because I can see some scenarios happening where end users could download a newer plugin that has some changes to a base class that could pollute older plugins and break them.
This is a fundamental software design problem you're butting up against: namespaces, and private vs. public in an environment with dynamically loaded code.
Obj-C doesn't have namespaces. That's why there's all the NSblahblah (or QCblahblah, or QTblahblah, or CIBlahblah) stuff out there -- the 2 letter prefix is a sort of defacto namespace standard.
private vs public is simple in C, but in Obj-C it's not -- you can't have a private class. If you make a class, it's always "visible" to the linker, so it will always get confused and do weird stuff when there are duplicates and new things get loaded.
To properly handle this, you've got a few options: * don't re-use classnames -- not what you want* make sure shared functionality uses just C-functions, and mark them as non-exported (the build option "Symbols Hidden By Default" under "Code Generation" will do this for you) -- you can also mark as non-exported via __attributes__ ((visibility("hidden"))) or something, but that seems much more annoying, and doesn't always do what I've wanted.
* for obj-c reuse, use a framework instead of in-code stuff. -- [ christopher wright ] [email protected] http://kineme.net/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
