On Jun 26, 6:22 pm, dbl... / wobblini.net wrote:

> Nothing that abstract or sweeping is at stake.  (I don't think
> Rubyists who dislike the thought of automatic class-checking are,
> overall, more subservient to their computers than those who don't :-)
> It's just that constraining Ruby method arguments to be of certain
> classes is both unnecessarily limiting and not as much of a guarantor
> of behavior as people sometimes think (since the objects don't "know"
> that they're supposed to ignore the side of themselves that allows for
> dynamic typing).  In the case of checking class membership in order to
> allow arbitrary argument order, you'd also run aground on the fact
> that a method might take more than one string, or whatever.

Is it limiting? Rubyists (myself included) love to wax grand about the
flexibility of Ruby's type dynamics. But I have to be honest, over the
years it's become clearer to me that reality is in fact more limiting.
Beyond symbol_or_string.to_s, and the like, how extensively do we ever
see duck-typing playing a roll in our code? On rare occasion perhaps,
but even then is it a serious feature? Or just a, "neato, look what we
can do" after-the-fact realization that never actually gets used? B/c
in reality, when we're figuring a parameter that our method should
take, we're not thinking about the methods it will respond_to. We're
thinking about the *type* of thing it is.

Granted Class-base typing can be too constricting, just as respond_to
typing can be too granular. What would be optimal is something more
fluid, that can encompass them or any shade inbetween --a way to
specify what something represents, not just how it's encoded. Take our
example above. We want two arguments, an Integer which represents an
*index* and a string which represents a *file*. Now there are a few
ways to represent a file actually, File.open(), Pathname.new(),
probably others. And yet, duck-typing isn't going to do a bit of good
if one of those is passed in instead of the String representation.

I think Ruby is a great experiment in this area, and undoubtedly it
shows some promise. In particular, mixins have a significant impact
our ability to use duck-typing. They allow us to think in terms of
common functionality --all thing Enumerable, or all things Sortable,
etc. It would be interesting to see how much further this kind of
generalization could be taken. Are there potential mixins we are not
using?

Slightly aside, but I would also point out that a language which is
serious about duck-typing would do well to support complete method
probing. We should be able to pass "decoy" parameters to any method,
acting in DryRun fashion, and record all possible calls made on them.
I suspect such a tool would be invaluable in ascertaining the common,
essential methods we apply to different representations.

T.