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