On Sep 4, 2011, at 4:55 PM, Mathieu Bouchard wrote:
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.
I think you are missing the point of what I am saying. I am not
saying with we implement a strict duck typing mimicing Ruby or
Python. I am saying we can be inspired by that. Pd is not OOP, so
trying to force it into an OOP structure does not make sense.
So in the sense of Pd, anything that can be intepreted as a number
should be. But that's in conflict with having symbols that have
things that can be intepreted as a number. So make Pd consistent,
either it needs to be illegal to have symbols that can be interpreted
as a number, or maybe symbols that can be interpreted as a number
behave like a float when something is expecting a float.
.hc
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs