Hallo, matteo sisti sette hat gesagt: // matteo sisti sette wrote: > Up to at least version 0.40.1, [list length] used to output the number > of arguments of a list or message (exactly as documented), which means > that [walk the dog( had length 2, not 3. > > Now, in 0.41-2, it treats the message as a list and outputs the length > of the list, that is [walk the dog( has length 3 which is the same as > [list walk the dog( > > Just compare how the help patch for [list length] behaves in version > 0.40.1 and in 0.41.2 (not sure where the change happened). > > This new behaviour may perhaps be "better" than the old one (it is > more coherent with the behaviour of all other [list] objects which > always convert any message to a list), however: > > 1 - this is DISASTROUS for backward compatibility. Patches written for > older versions will behave differently on the new version!
This has already been discussed in the past. The old behaviour was considered wrong. All [list] variants first convert their input to a proper list and all of them except [list trim] also output a proper list. Being able to rely on this makes patching with [list] objects much less error prone: When doing stuff with [list], there are no meta-message issues to consider. [list length] was breaking this rule, now it's fixed. Also it was considered to be confusing to have the length operator count a message "one two three" as having length 2 instead of 3. 3 is the better result in every usecase I can think of. The backward compatibility issue of course is there, but as 0.39 didn't have [list length], only one version of Pd (0.40) was affected by the wrong counting, so rather then wait any longer, the change was made as soon as possible. If there will be a pd-extended 0.40 I'd suggest to let "list length" count as the one in 0.41 immediatly. Note that [list-len] from [list]-abs, one of the alternatives to get the list's length for 0.39, always counted all elements including the selector. > 2 - the documentation (help patch) is unchanged, and there is no > ambiguity in it: it describes the old behaviour. You may have a different help patch than I: Mine doesn't describe this issue at all. However mine does say the following: "In general, inlets that take lists (two each for append/prepend, and one each for split and trim) will convert non-list messages (such as "set 5") to lists (such as "list set 5" automatically." Applied to [list length] this means, that 0.40 was buggy, 0.41 has the bug fixed. Ciao -- Frank Barknecht _ ______footils.org__ _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
