[PD] nosferatu namespaces
hans at eds.org
Wed Nov 23 18:10:29 CET 2005
On Nov 23, 2005, at 5:12 AM, Georg Holzmann wrote:
>> 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
> - 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.
> (but I think we already discussed this ...)
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.
More information about the Pd-list