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.