Hans-Christoph Steiner wrote: > > On May 20, 2008, at 3:43 PM, marius schebella wrote: > >> but if you use an abstraction inside another object, then all the >> variables of the parent patch should be available in the abstraction. >> additionally the local variables of the subpatch have higher priority >> and can overwrite the settings of the parent patche. >> >> object1 declares to use urn from cycling >> -- by default all abstractions created inside object1 would also use >> urn from cycling, except if an abstraction declares to use urn from zexy. > > This is exactly what I think would be a bad idea, then the > objectclass/abstraction depends on the parent patch. Therefore the > abstraction's/objectclass' functionality could change depending on which > parent patch it was used with. > > If this kind of functionality was really desired, there could be > namespaces like in Tcl which could be imported on their own. But this > would add a lot complexity with little gain, IMHO.
no, if you write a standalone abstraction, then you put a declare inside the *abstraction*, so that it is independent from the parent patch. but maybe I am wrong: here is what you are suggesting: you have a patch, named mypatch that includes an abstraction called abstraction1. you declare to use zexy for your patch. but then, instead of declaring this for your whole project you are proposing that all abstractions inside your patch should fall back to an arbitrary namespace (defined by individual startup flags) and not to the settings of the parent patch. that does not make sense to me. startup flag: -lib cyclone MYPATCH [ - declare zexy - // this is the namespace of mypatch, urn is the urn from zexy - abstraction1 [ --- // not using a declare here means urn is taken from cyclone - ] ] I think there is a rule that says something like "keep the namespace for a variable as local as possible." marius. _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
