[PD-dev] A Solution: abstraction and external name collisions

B. Bogart ben at ekran.org
Fri Apr 23 19:23:51 CEST 2004


Hey all,

I just had an idea suddenly inspired by Frank's RRADical announcement.

There has been a lot of talk about naming collisions and such on the 
list (indeed I have also been a victim myself of such issues) having to 
do with abstractions and objects. I started by naming my abstractions by 
the project they belong to ie v_[name] and pt.[name] but I realized 
something that could make managing this stuff a lot easier (Though it 
could make object names much more verbose, and could cause a hell of a 
time with existing patches being broken)

For example I have an Gem abstraction that does pix filtering called 
pt.layerfx.pd this abstraction is in one of the PDs paths. This 
abstraction depends on a number of other abstractions that are at a 
lower level. These abstractions are not meant for the person patching 
but only to make things easier for pt.layerfx. I have taken a few of the 
pix_ filters and wrapped them in abstractions to standardize their 
interface. They all have one inlet for the amount of the effect (from 
0-1) and an inlet and outlet for the gem-chain. These lower-level 
abstractions are in a sub folder of the folder that contains pt.layerfx 
called fx. Since the sub folder "fx" is not in the PD path typing "rtx" 
(the name of one of these wrapper-abstractions) for example gives me no 
valid object. Though if I type fx/rtx I am actually calling the correct 
abstraction, even though that abstraction is not in the PD path.

One could then organize their abstractions by the project and add only 
the folder of projects to the path rather than the individual project 
folders. This way you use a more verbose name to get at all the same 
abstractions without name collisions. A folder of cvs abstractions that 
may not be stable for example could be called as cvs/pt.layerfx and the 
stable version could be called simply as pt.layerfx.

Could this method be applied to externals as well?

markex/counter or mex/counter
cxc/counter
cyclone/counter or cyc/counter

Of course you break all the old patches if you have to use new names, 
but it provides a facility where you use the object you want rather than 
the one with the same name as the object you want. Shorter project 
names, or project aliases could be used for shorter names pt.layerfx 
becomes pt/layerfx. Someone could always put the cyclone folder into the 
PD path and then "counter" would refer to cyclone, and if you want the 
markex version you type markex/counter.

So there are issues with this method but I think it has potential. 
Obviously it could use development but I think the concept has some 
validity. In a way this is creating a seperate namspace for each set of 
abstractions/externals. They could also be multiple levels deep:

cvs/markex/counter
cvs/cyclone/counter
markex/counter
cyclone/counter

Just throught I would throw it out there as fast as it popped into my 
brain.

Any comments?

Ben





More information about the Pd-dev mailing list