[PD-dev] future of [declare]

[Matt Barber]

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 at 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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>