[PD] Re: Mac OS X installer with library documentation

Hans-Christoph Steiner hans at eds.org
Tue Mar 29 23:11:30 CEST 2005


I totally agree that namespace pollution is a real problem that we  
should strive to control.  This can be done while also including  
everyone's objects without changing the way Pd currently operates.

If we have the core objects directly in the standard path (../extra),  
then we can have the various additions in subfolders of that path.  As  
long as the objects are compiled as individual files, they can be  
instantiated separately.  A while back, I posted an example of this  
using various [prepend]s.  It was like this:
[object_name], [subfolder/object_name], [subfolder2/object_name].  All  
of these were different versions of "object_name" running in the same  
patch.  The only problem here (AFAIK) is the help file namespace, and  
there is probably a way around that.

So we could do this with vast amount of objects sorted into various  
extra categories, like 'deprecated' (and even things like  
'deprecated/gem'), 'contrib' (a free-for-all location), 'cyclone'.   
Also, we can do things like 'cxc', 'grill', 'iem', and 'ggee' for the  
various versions of [prepend].

I plan on trying this with the next Pd.app that I build.

.hc

On Mar 28, 2005, at 10:29 AM, Krzysztof Czaja wrote:

> hi Hans,
>
> the real problem is namespace pollution.  Just imagine people's
> anger, when their patches are broken by someone adding yet another
> little odd external to cvs build system, and the name they have
> chosen for their abstraction changes meaning without even
> a slightest warning.
>
> The predefined set should not exceed a few hundred names, with
> every addition carefully thought out and clearly advertised.
> Otherwise, Pd will grow into an unmaintainable, amorphous monster,
> that collapses under its own weight.
>
> All predefined classes should have their functionality cast in
> stone.  Everything else should be explicitly declared for a patch.
>
> The actual evil are not libraries, but using the "-lib" option,
> and likewise the "-path" option, as Pd's name resolution mechanism.
>
> Krzysztof
>
> Hans-Christoph Steiner wrote:
>> Basically all of the issues surrounding using libs can be eliminated  
>> by  compiling externals as individual objects.  I have been working  
>> towards  this for a while, so that you don't need to edit any prefs  
>> in order to  have access to all of the available objects.  The only  
>> downside that  has been confirmed with the individual files vs.  
>> libraries is that  someone has to do the work to convert libs into  
>> individual objects.  I
>>

________________________________________________________________________ 
____

"If nature has made any one thing less susceptible than all others of  
exclusive property, it is the action of the thinking power called an  
idea, which an individual may exclusively possess as long as he keeps  
it to himself; but the moment it is divulged, it forces itself into the  
possession of everyone, and the receiver cannot dispossess himself of  
it."

                                                     - Thomas Jefferson





More information about the Pd-list mailing list