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

[Mathieu Bouchard]

On Sat, 21 Jul 2007, Thomas O Fredericks wrote:

> In what case do you rely on using [unpack 0 0 0] except for throwing an 
> error when it receives a symbol? As it was previously suggested on this 
> list, why use anything else than [t a] or [t b]?

Actually, there is one single use for [t f], which has to do with a 
distinction that GridFlow needs. Originally, in jMax, a float atom or int 
atom was something clearly distinct from a list containing only one such 
atom. In Pd, the distinction is supposed to be ignored but Pd still makes 
that distinction and GridFlow still uses it because I never thought about 
any sensible replacement for it. I have a problem with that 
auto-conversion, especially as there isn't much of any other kind of 
auto-conversion that ever happens in pd (can you think of anything else 
like that?).

> I think Mathieu's end of type restrictions is a great idea. For example, 
> if you use Max/Msp every so often, you regularly curse at the useless 
> int/float type restriction.

int-vs-float is just a distinction.

An example of a restriction, is to forbid the use of float in an int 
context. An example of a useless restriction is to get the user to choose 
between "int context" "float context" "symbol context" "pointer context" 
in advance because no "any-atom context" is offered.

The int-vs-float distinction is useful because with ints your counters can 
go up to 2147483647 whereas with float they can only go up to 16777216, 
and yet float can handle things than int cannot.

> Mathieu, you would only need to create a new object that would determine the
> type of the data (unless your new [route] still does this).

The new [route] still does this because it is expected from [route] that 
using symbol arguments will match the selector of the message; the basic 5 
selectors are: bang, float, symbol, pointer, list. ("anything" is not a 
selector, it's the collection of all other possible selectors together)

> For example, I sometimes use [route bang list symbol] to parse data by 
> its type when an abstraction has many different "functions" attached to 
> the same inlet.

The only way that my type restriction removal may affect normal patches, 
is that it will remove a need to use [route] where it was previously used 
to work around a restriction; that's an optional change, but I usually 
jump at every opportunity to make patches simpler to read, understand, 
explain and modify. (supposing that "making a patch less generic" doesn't 
count...)

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada