[PD] [PD-announce] the end of type restrictions

[Frank Barknecht]

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?

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__