[PD] declare who? what?

[Roman Haefeli]

On Tue, 2008-06-03 at 09:59 -0400, marius schebella wrote:
> Roman Haefeli wrote:
> > when writing a patch, i don't want to think about the dependencies of
> > the abstractions i use. that is why i propose the following layout: 
> > 
> > in my idea of an ideal [declare -std*] layout, it expands search pathes
> > only locally to the patch and all its children (abstractions and
> > abstractions of abstractions). the same goes for abstractions: search
> > pathes are added for the instance itself and all children, but not for
> > the parent patch nor other instances at the same level. search pathes
> > added by the local [declare] should be checked _before_ the parent
> > [declare] before the grandparent [declare] etc. 'relative' means always
> > relative to the location of the file and not relative to file location
> > of the most top parent patch (or anything else).
> 
> hello roman,
> I totally agree with you. that should be the default behaviour. But iirc 
> the current behaviour is the opposite way. objects loaded in an 
> abstraction expand their paths to the parent patch.
> maybe this is because they are loaded first?
> maybe it is not possible to have local namespaces at all (everything 
> global?)?

ok. got that. is this the reason, why miller wants to disable [declare
-lib/path] inside abstractions in order to not pollute the parent
patch's search path space? so, at this moment, it's a purely technical
problem?
it would be good to know, if it's only a technical problem, because i
had the impression, that it is even unclear, how [declare] is supposed
to work (besides the problem how to make it work how it is supposed to
work). it would be good know, that there is no need for discussions
about the ideal behaviour of [declare] anymore.

roman


	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de