[PD] nosferatu namespaces
Hans-Christoph Steiner
hans at eds.org
Wed Nov 23 18:10:29 CET 2005
On Nov 23, 2005, at 5:12 AM, Georg Holzmann wrote:
> Hallo!
>
>> note that the library does not have to implement an object of the
>> same name. e.g. there is no [Gem] object in Gem, but you still can
>> load Gem by creating an object [Gem]: the creation will fail but Gem
>> will be loaded.
>
> yes, an other problem is, that e.g. [zexy] has to be created before
> [nop] ...
>
>> i think that the [using] object should automatically add (an
>> optional) library-prefix to objects that cannot be found.
>> imagine you have a patch that contains [using zexy] (how comes this
>> discussion always concentrates on my libraries...) and [nop].
>> since pd cannot find a [nop] object anywhere in it's space, it would
>> try to find [zexy/nop] which eventually is an abstraction
>> ./extra/zexy/nop.pd and thus can be resolved and loaded.
>
> yes, two things about that:
> - this should be local to each abstraction (otherwise reausability of
> abstractions is not guaranteed - there could be nameclashes ...)
Yes, for sure. But that'll be a much bigger project. For now, [using]
will probably just use the same mechanism as loading a lib with -lib or
whatever.
> - there should also be a way to not load all externs of a lib (like in
> python "import nop from zexy" or in C++ "using zexy::nop" ...)
The libdir format/geiger namespaces do this if the objects are
individual files. i.e. [zexy/drip]. This is one of the many reasons
why the Pd-extended builds avoid the old lib format whenever possible.
.hc
>
> (but I think we already discussed this ...)
>
> LG
> Georg
>
________________________________________________________________________
____
Man has survived hitherto because he was too ignorant to know how to
realize his wishes.
Now that he can realize them, he must either change them, or perish.
-William Carlos
Williams
More information about the Pd-list
mailing list