On Sun, 4 Sep 2011, Hans-Christoph Steiner wrote:
One possibility is to do a more duck-typing approach. For something that accepts only symbols, it'll happily accept "43" as a symbol. For something that only accept floats, it'll convert the symbol "43" to 43 and accept it as a float. The question here is how to handle it when something expects both floats and symbols. As far as implementing this, we could add to the t_symbol struct a flag to say whether it can be read as a float, and store the float value there too.
Duck-typing isn't about conversions...
Duck-typing is that a float-like thing is anything that «behaves» as a float. Thus, for any atom-type that could be considered float-like, there needs to be a set of functions that apply to any float-like thing.
The term Duck-typing was invented to talk about certain cases of hiding the implementation of something, especially the idea that inheritance and type-checking don't matter as long as the type you want to use has the appropriate functions attached to it.
The duck-typing term only applies to things for which you can attach functions (methods) to types. Thus it can apply to pd objects, but not to pd atoms... t_atomtype isn't similar to t_class... there are no tables of functions to be used for different situations on different atomtypes.
http://en.wikipedia.org/wiki/Duck_typing
In Pd, duck-typing happens with the "dsp" and "loadbang" methods, in which from the standpoint of pd, a dsp-object is any object that has a dsp-method, and a loadbang-object is any object that has a loadbang-method, without any further declarations that might explicitly mean « this class is in the DSPObject (or Loadbangable) category » or anything similar.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC