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__