Patches item #1544083, was opened at 2006-08-21 13:14 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1544083...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: wishlist Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: alternative names for [list] objects
Initial Comment: this patch adds alternative names with space " " changed to slash "/" for the group of [list]-objects:
[list append] == [list/append] [list prepend] == [list/prepend] [list trim] == [list/trim] [list split] == [list/split]
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-08-22 18:24
Message: Logged In: YES user_id=27104
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.
This could be achieved by compiling the list objects as a libdir.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1544083...
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?
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.
This could be achieved by compiling the list objects as a libdir.
how do you compile internal objects as a libdir?
mfg.adr. IOhannes
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
On Wed, 23 Aug 2006, Hans-Christoph Steiner wrote:
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.
What's a "collection" of classes? Most files in the pd source would qualify as a collection of classes, yes?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Aug 23, 2006, at 2:08 PM, Mathieu Bouchard wrote:
On Wed, 23 Aug 2006, Hans-Christoph Steiner wrote:
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.
What's a "collection" of classes? Most files in the pd source would qualify as a collection of classes, yes?
Sure, and they could easily be libraries. But I think you all know what I am talking about.
.hc
------------------------------------------------------------------------
On Wed, 23 Aug 2006, Hans-Christoph Steiner wrote:
On Aug 23, 2006, at 2:08 PM, Mathieu Bouchard wrote:
On Wed, 23 Aug 2006, Hans-Christoph Steiner wrote:
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.
What's a "collection" of classes? Most files in the pd source would qualify as a collection of classes, yes?
Sure, and they could easily be libraries. But I think you all know what I am talking about.
Ah, now I understand. You wanted to say that classes in x_list.c hide behind a creator (class_addcreator) which acts as a namespace which is not the kind of namespace that you are pushing, but which is nonetheless the kind of namespace that Miller is pushing, by the very fact that Miller added this system very recently. The fact that it has its own namespace makes you want to call it a library in your terminology, despite the fact that Miller doesn't call it a library. Right?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
SourceForge.net