[PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)

[Frank Barknecht]

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__