On Wed, 4 Jul 2007, Frank wrote:

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"

Oh, I thought that this was a feature :)

...

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.

Oh, I didn't know that you needed them to still be called [counter] in the end, just that there are 5 classes named [counter] at one point and that something is done to resolve the conflict in some way. If you don't ever instantiate it as just [counter] then you may as well consider the prefix as part of the new name, such that [whoever/counter] is still in some way also a renaming of [counter].

And of course there is the social problem: How is it decided, which counter should keep its name?

So far, I don't remember anything about a decision committee (of any size) which would consist of pd users. There was some vague mention of democratic processes in the pd developers world, that did not get backed by answers to questions like: who would have the right to vote? would all votes be considered equal? how would votes be conducted? what would the questions be about?

As long as no-one attempts to answer those questions then this situation will continue. If no-one attempts it, it might be because the current situation is not so bad or people have resigned themselves to be less picky, whi

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".

That's one more example of the pattern that people who are the most able to solve the problem are the ones who feel the least affected by the problem.

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?

Because software is released as archive files (.zip or .tar.gz). Those, by convention, are made to contain one big folder; else, someone uncompressing them would create that big folder, to hold the contents of the archive, so that it's easy to know what is in use and easy to remove it, replace it or disable it, just like it's easy to handle a folder. Now, at the same time, people don't want to use fully qualified names. Developers are people, and they make the decision to call an external [list-map] instead of [list-abs/list-map]. Because of this, -path is necessary.

The other possibility is a package management system that puts all files together in one tree yet remembers which are part of what. This solves some problems and bring some fresh new ones, such that name conflicts can't be resolved (e.g. there can't be two files named /usr/sbin/sendmail at once...)

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. ;)

The bit-rot, according to previous definitions, would happen when support for extraneous forms of class-names gets removed. I figure that this could happen if a class browser reveals that it really sucks to have each class multiple times under slightly different names, unless there's some way to identify which names are "canonical" and which names are "aliases". In such a case, the class browser could have the ability to hide all aliases, or hide just the unnecessary prefixes.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada