[PD] the behaviour of [list length] has changed!!

[Frank Barknecht]

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__