[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