[PD] pdmtl abstractions questions and comments

[Mathieu Bouchard]

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