Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
You will be happy to know that the pdmtl abstractions have given up (for a couple of months now) the [pdmtl/list/op] style of naming it's abstractions.
In favour of [list/op]? That's what I wrote. Or did I miss something?
By building the pdmtl abstractions layer, users do not have to care about namespaces anymore (anyways, I don't), as all externals/libraries are treated as hidden code to the end user. I still believe that having namespaces based on authors is a bad idea.
Yes. And no, too. I believe, there should be several standard, function-based namespaces. Kind of like pdmtl internally is, but in my opinion, classes in these "STD"-library should have implementations without any dependencies besides Pd core objects. At least that's the guideline I tried with the [list]-abs: Abstractions in that library must not use externals *at all*. (See the end of this mail for my reasoning.)
Then, as an additional layer, versions of these classes could be provided, that do use externals. So there would be two [list/drip] implementations: One using only [list ...], another using [drip] from Zexy for speed reasons. This could then shadow the purepd-version, when Zexy is available, for example in pd-extended. In fact, I'm already using many of these external-enhanced variations of [list]-abs locally.
This way, patches using [list/drip] would run everywhere, even without Zexy. Being dependency-free they could be used by everyone regardless of how this everyone has his/her system and search path configured.
The ideal solution would be to add alternate names to many externals (like zexy's length could have one additional line of code that would instantiate it with list.length, by registering "list.length" as: class_addcreator((t_newmethod)length_new, gensym("list.length")...
I don't really understand which problem alternate names would solve?
But then you would need an editor in chief that would decide what objects get what alternate names. I think the best would be to hold an election for the "editor in chief" that would make all the needed changes.
But honestly I do not think this is going to happen as there are many issues that this thread has already enumerated. In my own opinion, I would say "give up" and find another solution. That's what we did :)
I honestly believe that without an "editor in chief" (which would be a group of editors or a voting process or a document with guidelines or ...) the nameclash and path setup problem for external classes isn't possible to solve. I learned that lesson from looking at how Python, Java, C/C++ and everyone else is giving away standard class namespaces and keywords.
So far we have one "editor in chief" and that is Miller Puckette who decides, what's in Pd-vanilla. Miller is the only constant, that's why Pd-vanilla IMO is the only working base assumption for a "STD"-library as I suggested above.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__