[PD] (breaking symbols) was Re: find a list of numbers in a text file

[Mathieu Bouchard]

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