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

[marius schebella]

Hans-Christoph Steiner wrote:
> 
> 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.
> 
> .hc


hi,
I realized that the example I gave in the beginning of this thread was 
bad, because it did not use declare at all!
And reading also the discussion on the similar thread (loooooooong) 
clarified some things. My intention is still to give patches a better 
structure for the future.
One of the things that changed my thinking was the fact that there is a 
difference between namespaces and searchpaths. If local patch/canvas 
namespaces are working, the whole "loading before" and "loading after" 
would become irrelevant. relying only on searchpaths means everything is 
dependend on the loading order of libraries, or object classes respectively.
but include, define, require, declare, import, loadlib, loadpath all 
have slightly different meanings...
It would be cool, if the behaviour would be better pointed out; the 
current and the future one, too. that would make the whole mechanism 
more clear, comprehensible and traceable.
that said, back to the problem of declaring relative search paths in 
abstractions.
the idea of adding a relative path is that instead of writing 
path/to/my/folder/someresource1.xyz one could write
[declare -path path/to/my/folder] and then references someresource1.xyz 
without the need to type the path over and over again. that is useful 
for resources like images or soundfiles, (the question whether this 
should also work for abstractions too, is still undecided).
situation 1: the abstraction depends on resorces that are relative to 
the abstraction directory. no question this situation will appear and 
can only be managed, if relative paths are relative to the file location 
of the abstraction.
situation 2: An abstraction wants to access a folder that is relative to 
the file location of the pd-patch file that nests the abstraction. for 
example a slideshow-abstraction that should grab 20 images of a folder 
relative to the parent patch. in this case [declare -path $1] inside the 
abstraction would try to find the folder relative to the abstraction 
location instead of the "parent" patch loacation. This is already the 
case if sending a relative path to an object in an abstraction like
[open path/to/resource.xyz(, which is/was always relative to the file 
loaction of the abstraction, even if you use [open $1( and feed the path 
from outside.
so after all, I guess Reverend Roman was right. the solution for 
situation 2 would be to put the declare object in the patchfile to which 
the directory is relative to.
cheers,
marius.