[PD-dev] [ pure-data-Patches-1544083 ] alternative names for [list] objects

Hans-Christoph Steiner hans at eds.org
Wed Aug 23 18:06:08 CEST 2006


On Aug 23, 2006, at 3:57 AM, IOhannes m zmoelnig wrote:

> SourceForge.net wrote:
>> Submitted By: IOhannes m zm�lnig (zmoelnig)
>> [list append]  == [list/append]
>> [list prepend] == [list/prepend]
>> [list trim]    == [list/trim]
>> [list split]   == [list/split]
>>
>>> Comment By: Hans-Christoph Steiner (eighthave)
>> I think this is a bad idea.  If there is going to use the
>> namespace-style prefix, then the underlying library should
>> be formatted the same way.  I don't think its useful to have
>> yet another special case for the list objects, which this
>> would be, especially when it does not add any new
>> functionality at all.
>
> i don't understand. what is the "library" you are talking about?

If a library is a collection of classes, then x_list.c (aka [list])  
is basically a library.  So the list library is the one I am talking  
about.  x_list.c can easily be compiled as a multi-class-single-file  
library.  In fact it was done that way for the last pd-extended release.

> the "special case" for the list objects is there use of ' ' (space)  
> in the names (the arguments to [list] define its functionality).
> replacing the space with a slash brings (imo) the objects back into  
> the usual world, where the objects name defines the functionality.
>
> i chose "/" as separator as it fits neatly into the libdir format  
> and allows to have "list" objects both compiled into pd and  
> external (like abstractions) to be used the same.

I totally agree with the idea, it would be great. Its just the  
implementation that I don't agree with.  I think the "list/" part  
should use the already existing implementation for such things,  
rather than some new thing that old exists for the list objects.  Pd  
already supports loading objects in a folder using the relative  
prefix, ie /path/to/pd/extra/list/prepend.pd_linux can be loaded like  
[list/prepend].  That's worked for a long time.

So this would probably be more work, but its the cleanest solution in  
the long run, IMHO.  But your solution would be the quick and dirty  
way to getting this implemented.

>> This could be achieved by compiling the list objects as a
>> libdir.
>
> how do you compile internal objects as a libdir?

I am working on that (externals/corelibs).  Basically, for many of  
them, it'll be quite simple.  Just put the classes each in their own  
file, compile them, and install them into a libdir.  For the one with  
interlocking dependencies, it will more difficult.  Probably the way  
to do it is the way that Thomas did with flext in Pd.app: a shared  
lib used by classes compiled into single files.

Ultimately, I am trying to get all of the core objects to compiled  
into a libdir so then we have a real namespace, with basically  
nothing at its root.  Then you can easily override any object with  
your own, [route], [list], [trigger], etc.

.hc

------------------------------------------------------------------------

I spent 33 years and four months in active military service and  
during that period I spent most of my time as a high class muscle man  
for Big Business, for Wall Street and the bankers.      - General  
Smedley Butler






More information about the Pd-dev mailing list