[PD] declare [was: Re: Idiomatic Pd]

Hans-Christoph Steiner hans at eds.org
Thu Jul 31 05:32:08 CEST 2008

On Jul 30, 2008, at 3:15 PM, marius schebella wrote:

> Hans-Christoph Steiner wrote:
>> If we want to have namespaces working, then I suggest we use the   
>> tried-n-true model of other languages.  If people are really   
>> interested in experimenting with ideas of how to handle  
>> namespaces,  then we could try other options.  Either way, we  
>> should start by  getting the tried-n-true model working first,  
>> IMHO.  Then if people  want to experiment with things like  
>> inheriting namespaces from the  parent, there will be a solid,  
>> working foundation to build upon.
> what's the tried-n-true model? and why is expanding namespaces to  
> (sub)classes not part of tried-n-true? I think an inheritance model  
> should be introduced into pd.
> declare is intended to load libraries or objectclasses only locally  
> (only available to the patch that holds the declare object - since  
> 0.41 this should be the case.)
> for nested abstractions there are three possibilities: (1) don't  
> inherit anything, (2) inherit from parent to child, (3) inherit  
> from child to parent. (or several declare options that allow all  
> three possibilities.)
> I would like to "vote" for solution 2. but I think there are  
> technical problems with this option: afaik it is not possible to  
> "overwrite" a declaration. for now it is first come first serve. so  
> if an abstraction inside a nested patch wanted to use a certain  
> objectclass which is in conflict with the parent patch, that would  
> just not be possible.
> and another problem seems to be that abstractions get loaded first,  
> so the first come - first serve works even worse right now, because  
> it loads declarations of abstractions before the parent patch.
> please correct me, if I am wrong.
> I see usecases for method (3), too. if you want to throw a certain  
> set of declarations into all your patches as abstractions. but I  
> think this causes more problems than it solves. what if you have  
> two conflicting abstractions in parallel, that both try to set the  
> namespace for the parent patch?
> marius.

I think it is essential that each object be complete and functional  
no matter what  other things are setup in the namespace.  Having one  
patch inherit the namespace of the other could cause an object to  
break if a different [prepend] was loaded first, for example.

In order for objectclasses to be self-contained, there needs to be a  
canvas-local namespace for every patch that is checked before any  
inherited namespace.  That is missing right now.  There could then be  
a "parent" namespace, then there is already the global namespace.   
Personally, I think this is overly complicated.  I think that global  
and canvas-local is enough.  Those two are the essential ones.

Python, for example, does have more levels, like the "module" level  
namespace, which could be seen as a kind of parallel to a "parent"  
namespace. As long as there is a true canvas-local namespace, then  
this is a workable option.



If nature has made any one thing less susceptible than all others of  
exclusive property, it is the action of the thinking power called an  
idea, which an individual may exclusively possess as long as he keeps  
it to himself; but the moment it is divulged, it forces itself into  
the possession of everyone, and the receiver cannot dispossess  
himself of it.            - Thomas Jefferson

More information about the Pd-list mailing list