Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
[unpack] does not have default values. If you unpack a list of length 2 using [unpack 0 0 0], the last outlet won't be used. The zero is never used as a float. So, if one believes that the type declarations only have to do with former limitations that have been overcome, the actual arguments of [unpack] may be ignored, and instead the actual values of them may be used.
Actually a thought occured to me: If the arguments of [unpack] should not also specify their types, why do we have these arguments at all? As I see it, then they would only be there to specify the number of outlets. However using the argument count to specify the outlet count is really awkward IMO, a much better approach (especially when used with abstraction arguments) for this would be to use a number directly to specify the outlet count.
So instead of [unpack 0 0 0] an [unpack 3] would create an unpack with 3 outlets for any kind of atom. But as this of course is damn incompatible with old patches, a new class name should be used. A candidate for this would be an "unpack method" for [list] like [list unpack 3]. Miller already considered a method like this in a comment in x_list.c. Then also a [list pack 3] could be introduced as a type- and default-value-less synonym for [pack 0 0 0] (or [pack e e e]). How does this sound?
Frank Barknecht _ ______footils.org_ __goto10.org__