[EMAIL PROTECTED] wrote: > On Monday 01 October 2007 15:36:02 IOhannes m zmoelnig wrote: >> appreciating that you found a bug in [lister] (which has been around for >> quite a while and i do believe it was useful and used), i cannot follow >> your arguing: >> though shalt not use aliases for buggy objects >> though shalt not use 1-character names for buggy objects >> though shalt rename buggy objects to [buggy_<objectname>] >> though shalt not use buggy objects >> though shalt not write buggy objects >> >> not much left to use then... > > Did I write anything that could be interpreted as offensive ? If yes I'm > sorry.
no no. i was just saying that your consequence from a buggy object was a bit too much for my taste. > I'm not blaming anybody for the (arguably small) issue at hand, we were just > discussing the reasons why one would expect certain objects to have shortcuts > or not. Of course "bugginess" can't be a criterion as nobody knows a priori > whether if his code is 100% error-proof (and nobody can honestly guarantee to > write bug-free code). right, that is what i was trying to say. > However, in this particular case, since we know there > are a couple issues with [lister] how many issues do you have with lister. in all the years of its existance, i remember exactly 3 bugs filed at the sf tracker: - sending data to the 2nd inlet while the outlet is still sending corrupts the output. - the help file speaks of "a nonexistant [list] object" - the object shouldn't be abbreviated [l] and then there is another "bug" which has not been filed to the tracker yet: - [lister] can be replaced by [list append] so we have 4 issues, and honestly all but the first ones are not "bugs" in a strict sense. which leaves us at only 1 issue (which has been fixed in the CVS) > and since I was told it could be deprecated > in favor of [list append], my opinion is that maybe the shortcut should be > assigned to the latter in order to prevent people unaware of pd's historical > development to choose the former. well, in theory this is correct. in practice there are several issues: - [l] is _not_ yet a shortcut for an internal list object. however, some object has to provide the (bug-free) functionality of [l], in order to not break existing patches - [list append] is _not_ exactly the same as [lister]. you can make a [lister] (or [l]) _abstraction_ with built-in objects: | | [route bang] | | | | | [t b a] | +----------+ | | | +--+ [list append ] | - afaik, this patchlet is 100% compatible, if you feed all the arguments of [lister] to the [list append] replacement. - this patchlet cannot be made into a 100% compatible _abstraction_ with pd-internals, because there is no way to pass a variable number of arguments to an abstraction. you would need my "$@" patch against Pd for this. these are the reasons why there still is a [lister]/[l] object in zexy and why it is done as an external. on the other side, a lot of objects in zexy are there only because they aren't there in Pd yet (for instance, zexy had a [tabread4] object long before Pd...) i would love it, if Pd's [list] object (which is an alias to [list append], would really behave in-line with the [float] and [symbol] objects (see above patch) i would love it, if this [list] object would have an alias [l]. fmg.asdr IOhannes _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
