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

[Hans-Christoph Steiner]

On May 20, 2008, at 5:55 PM, marius schebella wrote:

> 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.


I am saying that the namespaces should either have effect globally or  
only for one patch/abstraction/objectclass.

.hc

------------------------------------------------------------------------ 
----

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.    -William Carlos Williams