From: Robert Dober <robert.dober@...>
Date: 2007-06-27T14:45:58+09:00
Subject: Re: Named/positional method args

On 6/27/07, Trans <transfire@gmail.com> wrote:
>
>
> On Jun 26, 6:22 pm, dbl...@wobblini.net wrote:

>
> 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?
I do not know Tom, one application springs into mind, I am generating
iptables commands from a DSL. The outpout is done via #<< to an object
(defaulting to $stdio) for testing I just set that object to an array.
> On rare occasion perhaps,
> but even then is it a serious feature?
A rare occasion, yes, but a very serious feature indeed.
>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.

That, IMHO, is because your example is not about Duck Typing, as
Strings and Files do not quack and walk alike.

We could make them so of course, and I wonder why I have not done this
before, given that this is indeed a common pattern in my programs too:

class File
  alias_method :open_as_file, :open
  def to_file; self end
end

class String
   def open_as_file *args, &blk
      File.open(self, *args, &blk)
   end
   def to_file *args
      File.new( self, *args)
   end
end

Now you have Strings and Files that talk and walk alike.
I do not like the expression "Duck typing" too much (Rick's dog
notwithstanding ;) I feel more like "using protocols".
Ruby gives you the power to implement those protocols but you have to
implement some of them yourself ;)

>
> I think Ruby is a great experiment in this area, and undoubtedly it
> shows some promise.
Smalltalk? 35 years ago, I think Rick confirmed the now famous Alain
Kay quotation about Smalltalk beating Java, but being called Ruby.

I am however eager to learn subtle differences in the two "duck typing" models.

> 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?

And eventually I agree with you :)
>
> 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.
>
Hmm me bad, I do not understand this, could you mabye give an example please?
Thx and cheers
Robert
-- 
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw