Krzysztof Czaja wrote:
hi IOhannes and all,
So, I really do not know, if this is going to be a real step forward, or just a fuel keeping this thread alive for some more time?
neither do i know. however, i would like this thread to be finished sometimes and that is why i did write some code. it was hacked quite fast without real stress tests and the idea seemed ok to me.
i just don't want this question to pop up every other week
However, if this encouraged people to use names of existing externs for their redefined versions -- on the ground of ``always being able to use a qualified name'' -- it would be a very bad thing, causing confusion, and making many patches hard to reuse...
confusion starts right now:: i (having slept little) cannot think of really bad scenarios. let's try: xy uses zexy and labels all used zexy-classes with the qualifier "zexy::" sometimes later someone decides to enhance zexy and makes his own (more or less compatible) version called "hexen" when xy decides to upgrade from zexy to hexen he would have to reprogram all his references to the library-objects ! xy could use searchnreplace (not that bad, but some work)
another try: xx uses ggext compiled as a big library and consequently uses the "ggext::" qualifier. by pure chance, one rainy day xx compiles ggext as a collection of separate externals. everything is broken
my aim was, just to allow (!) the using of qualified names. if i do load 2 libraries providing the same class-names i have to use some mechanism to access the objects. i do not encourage the use of qualified names when writing patches. i do encourage the use of them when name-clashes arise.
In the comments below I assume the former...
please do not call this feature `namespaces'. From just being
ok ! "qualified names" it be then
(of course it might not prove optimal, but which solution would be ? i think this is the cleanest solution from a programmers point of view)
ok, but there is a (confused) user's pov too...
"programmer" meaning "someone programming in the graphical language of pd"
by the way, somehow i am now convinced that "." would be a better delimiter 8-) there is a new patch-file (hopefully more unified than last time) that applies Krzysztof's changes (thanks), uses "." as delimiter and fixes the bug "/my/long/path/to/externs/library::object" to "library::object" (without this we could then have concurrent versions of a single library running at the same time ....)
mfg..sd IOhannes
Krzysztof