[PD] Re: [PD-dev] Re: prepend w/ set message - ignore
mpuckett at man104-1.ucsd.edu
Wed Nov 10 18:18:01 CET 2004
Aha, so, if we keep "prepend" and "scale" max-compatible, we just need
better names for the "correctly designed" versions, no?
For prepend, at least, we could borrow an idea from Krzysztof and make
a new "msg" object:
.. this is assuming nobody has yet written a "msg" object, of course!
On Wed, Nov 10, 2004 at 05:29:26PM +0100, Frank Barknecht wrote:
> Hans-Christoph Steiner wrote:
> >On Nov 10, 2004, at 3:38 AM, Frank Barknecht wrote
> >>Technically I actually would prefer IEMlib prepend to be the standard
> >>[prepend] because of this problem, but Cyclone is more Max compatible.
> >>Btw: Both Cyclone and Zexy have [avg~]
> >There will always be problems with any approach. There was a
> >relatively lengthy discussion on this very topic before this decision
> >was made. I recommend reading that thread and addressing the issues
> >that were discussed that lead the Cyclone [prepend] to be chosen. I
> >believe it was a compatibility issue. I didn't make this decision, I
> >just acted on it.
> Me, too, in RRADical. ;)
> However, Johannes' question is valid: With Cyclone/Max-prepend it
> is practically impossible to prepend to lists starting with "set".
> That's where I see the need for iem_prepend, but the big question
> actually is, what approach should be used for the list handling
> *internals* for Pd, that were discussed in Graz. They also need
> an object that does prepending to lists. Choosing
> Max/Cyclone-prepend for this is a bad solution, because of
> Johannes' problem. Because of nameclashes, the name "prepend"
> also cannot be used while satisfying both the technical
> (prepend to "set") as well as the practical issues (nameclashes,
> backwards compatibility).
> Maybe we should use a whole new kind of names for the future Pd list
> functions, for example taken from the C++-STL conventions like
> "push_back", "push_front", "insert" and "erase" instead of the
> Lisp'ish "append" and "prepend"? A tempting idea.
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
More information about the Pd-list