On Jun 19, 2010, at 1:42 PM, Mathieu Bouchard wrote:
On Fri, 18 Jun 2010, Roman Haefeli wrote:
I am probably the wrong person to comment on the technical aspects,
but it seems to me that your proposal of having only a setup() function instead of the current classname_setup() function would render it impossible to have a c file provide more than one class. Or am I misunderstanding something here?No. You can define any number of classes in a setup().
In fact, you can do anything. I once made a library that would only
provide more aliases for existing (builtin) classes, so that I could
instantiate either [inlet] or [inlet~] by writing [inlet.$1] where
$1 was a parameter that could be f, s, ~, # or other.You can also add methods to existing classes. Thus GridFlow adds
methods "else", "last" and "last_activate" in the "canvas" class.
It's very useful to do so, but Pd doesn't have a plan for
documenting such a situation, because I can't provide a rightclick
helpfile for the extra methods. So, for now, they are still
undocumented, but they are used by [#in], [#many] and [doc_m]
respectively, among other uses...If you happen to have several files in a big library, and they each
have a setup(), you can name each of the setups differently and call
all of them from the main setup() of the library (except itself). If
you need a library to be compilable in both manners from the same
source, you can use compilation options such as - Dsetup=thisclass_setup or things like that, to rename a plain
setup() to a longer, unique name.
I am saying that each class should have a function called setup().
That's how it works in Max/MSP. I think that having a single function
called setup() load multiple classes is not a good idea. The thing
loading the classes just needs to know not to import the "setup"
symbol, just call the function.
.hc
If you are not part of the solution, you are part of the problem.