With a little difficulty one could have it both ways by adding something like a -exportpath flag -- an advantage for having abstractions export paths to parents would be to have a master abstraction with all the [declare]'s -- but more importantly it would useful for looking for other resources like textfiles for qlists and soundfiles for soundfiler but specifying the path relative to the parent rather than the abstraction (makes the abstraction behave like a builtin object) -- I haven't checked the behavior recently, though, so I don't remember the default action for resources.
Matt
On Fri, Nov 7, 2008 at 8:55 PM, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
Actually, I think it would be a bad idea to have an abstraction affect the search path of the containing patch. There would be no way for the patch to know about the stuff getting added to the path until the abstraction gets loaded... but you need the path in place to figure out where the abstraction should be searched for.
I think (probably as you're saying below) that an abstraction's declarations should affect only itself and things called from within it.
cheers Miller
Hi Miller, Isn't the benefit of declares in abstractions that you can modify the search path of just that parent abstraction and its children? If abstractionA is known to be the only one that needs the path "special-oscs/", there's no reason for abstractionB to be looking in there.
(or, perhaps you mean no one has proposed a situation in which it is a good idea, as declare is implemented currently)
Best Luke
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev