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.