[PD] pdmtl abstractions questions and comments
matju at artengine.ca
Thu Jul 5 06:02:10 CEST 2007
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
> Well, but then you wouldn't have five objects named [counter]
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
> 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
> 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
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
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
> 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
More information about the Pd-list