On Nov 1, 2006, at 6:49 PM, Mathieu Bouchard wrote:
On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote:
First off, how would this be different than [declare -lib]?
Actually, what does [declare] do?... I just remember some of the discussions about it vaguely, but if something's been implemented in pd lately, I haven't tried it.
Um, RTFM? There's a help patch, its pretty clear.
Personally, I think the syntax of [declare] is inconsistent. Nowhere else in Pd are cmd line style arguments used in object boxes.
They're used in Krzysztof Czaja's TOXY. I'm sorry if you only mean what Miller does. I don't think that a decision about this should only consider Miller's practice and no-one else's.
Sorry, that one slipped by me. Doesn't change my overall opinion.
It just doesn't feel right to me, doesn't feel Pd-ish.
It doesn't feel Miller-ish.
[import] just loads libs.
To get my approval, any kind of namespace solution should be local, so that what is imported by one canvas does not affect what is imported by another canvas, except if it's a subcanvas ([pd] or [page]). In other words, the boundary of a $0 is the boundary that [import] should not trespass.
I don't think that anyone disagrees with that. But there is, and should be, local settings. There are global settings also. That's probably needed for transitional support, and there might be a decent argument for keeping them in general.
One thing that might make sense for the global settings -stdlib and -stdpath is to make them message based, like [;pd lib zexy( or [;pd path /path/to/my/extra( With those in place, the flags wouldn't be needed.
I don't have anything against runtime configuration of pd's global settings, there just have to be a local setting or it doesn't deserve to be called namespaces.
[declare] does both local and global.
.hc
------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.