[PD-dev] the future of [declare] and canvas_savedeclarationsto()

[marius schebella]

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.