hi all,
it is so hot here, thinking is so hard and painful... are there cooler places on earth, where pd-dev people live?
...say, we have 150 classes using some amount of a common code. The size of this common code is rather small -- close to the average size of one class' code, or possibly 2 or 3 classes. Some of the options are:
1. All classes, and the common code, are statically linked in a one monolithic library.
2. Each class is kept as a separate external, linked with the common code (which means: there are as many common code copies, as the number of externals containing it, and loaded during a Pd session).
3. The common code is linked dynamically, and it has to be loaded prior to any of the classes (using an explicit -lib option).
4. Class names are prefixed with a library name, causing Pd to load the library with both the common code, and the classes (a feature not yet available, but already discussed on pd-list).
5. Like 4., but the library contains only the common code -- its setup routine has to know what particular class is demanded, and how to load it.
6. Each class uses a tiny ``stub code'', possibly a part of a future Pd api, which somehow checks if the common code is already loaded (currently it might be done by checking if something 'familiar' is bound to a particular symbol). If not, it loads the library, and obtains a set of pointers to the functions in the common code.
Are there other options? Which option is best?
Btw, perhaps due to my mind melting in the heat, I somehow tend to like the method 6 (if only it was a part of Pd api...)
Btw, options 4/5 cannot be applied in case of the cyclone library. They might be in case of xeq or vexing (currently both are using a modified version of the first method, while a cyclone user has to choose between options 1 and 2).
Btw, there are not as many classes in cyclone (yet:-?) just a bit over 40, but it keeps growing...
Krzysztof