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
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
