Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
If someone else does an abstraction collection for lists, I'd say, "list_" or "list." are two other good choices.
So far, Max seems to be using ".", for example "jit."; because of this, I've used the "." prefix but for "lti." classes; actually I also used it for some PureUnity classes, initially like "f." "~." "#." to mean float's, signal's, grid's, in a way that is meant to be used as [$1.hello]. I have changed this to around to [hello.$1] because of pd 0.40 and of personal preference.
There is a minor annoaynce with the dot for abstractions ATM because of an unfixed bug: If you save a new abstraction that already has a dot in its name like "list.abs", you need to add the ".pd" extension manually, otherwise Pd will save it as "list.abs" instead of "list.abs.pd". This is not a problem with "list-abs" which gets the suffix added automatically by Pd.
Where directory prefixes shine however is for making packages of externals and abstractions. Pd-extended is the prime example: It can ship all five [counter] objects, which would be impossible without subdirectories for each collection.
Edit the five source files, changing the name in it for something else. Is that so impossible? It might not be pretty, but I wouldn't call it "impossible".
Well, but then you wouldn't have five objects named [counter] anymore. And of course there is the social problem: How is it decided, which counter should keep its name? And that is actually what I meant with this:
All this to me seems to kind of pervert what Guenther Geiger actually intended when suggesting directory prefixes and initiating the CVS-repository.
IIRC one motive to start the CVS was to get rid of objects that do slightly different things but have the same name (like the [counter]s) by first collecting them all in one place (Sourceforge), see what's duplicated and/or conflicting, and then decide on the one "real" counter - possibly keeping the four others with different names.
Unfortunatly we didn't get further with developing an infrastructure to decide things like that.
Actually, it never occurred to me that those two things were related. I think that I joined pd-list shortly after the CVS created, but I don't recall that anyone said (in the last five years of pd-list) that the whole externals/ thingie had to do with Geiger namespaces.
The namespace and the CVS are not related directly, I didn't want to imply that. Geiger namespaces are just way to keep the four other [counter]s from above available, in case someone needs them. However I fear, that they also became a kind of excuse to not think about developing a way to decide things like "which [counter] to keep".
and the "Path" window is filled with more entries than it can handle.
Apart from what the intention might have been about paths or libs (libdirs), this is not a problem with Hans's work per se, it's a problem in u_main.tk, and it's very possible to fix it: e.g. http://artengine.ca/desiredata/gallery/pdrc_5b.gif and the same user interface also exists for -path and -helppath separately.
Of course one could easily overhaul the path windows (and one has to do it for plain Pd as well) to be able to handle more paths, but the actual problem is: Why are there so many paths and are they all really necessary?
[list-abs/list-abs] is bit-rot.
Well, i've only seen the word "bit-rot" to mean things that result from not updating software to changing interfaces (I'm not counting the meaning of it that has to do with physical media). Thus I don't really know what you mean by [list-abs/list-abs] is bit-rot: it's not like your [list-abs] has gone unmaintained for years such that the definition of pd (or what pd is in practice) has changed such that is has become contextually broken or outdated or irrelevant...
I meant: Using [list-abs/list-abs] instead of just [list-abs] is a kind of bit rot, because the more people use the double or triple prefix, the more it gets carved into (some) stones and at some point, users will expect the [list]-abs objects with long names to be available. Maybe that's not something to call bit rot, but it would be rotten. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__