From: Trans <transfire@...>
Date: 2007-06-28T01:30:07+09:00
Subject: Re: Named/positional method args

On Jun 27, 1:45 am, "Robert Dober" <robert.do...@gmail.com> wrote:
> On 6/27/07, Trans <transf...@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.
>
> A rare occasion, yes, but a very serious feature indeed.

That's a pretty good example. It's easy to effect because it's based
on the single method #<<. And I've used it too.

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

Well, that's kind of my point. We use a string to represent a file,
even though it's not a file. Our representation don't necessarily
correspond to actual types.

> 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

Nice. You were able to put duck-typing to better work for us. But I
want to emphasis my point here. You were able to do this by thinking
in terms of *types*. When accepting parameters, you still think "a
File-like thing". With you're code it can now be a String or a File.
It's not really limiting to specify types in method interfaces. We are
rather limited by not having good means to properly specify those
types. So understandably we opt not to specify them at all. It's
always possible to have an object pretend to be something else:

  class Chameleon
    def self.===(other)
      true
    end
  end

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

Ah, right you are. And I'd like to know too. Have Ruby advanced "duck
typing" or has just given us a lite version?

> > 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 :)

:) I'm not really arguing against duck-typing. I just don't think it's
necessarily in opposition to specifying optional parameter types. If
the the whole duck-typing idea was more deeply pursued we might even
find it quite intuitve to do so, using Mixins:

  def foo(a < Enumerable)

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

A method probe is something like this:

  class Decoy
    private *instance_methods
    attr_accessor :_record
    def initialize()
      @_record = []
    end
    def method_missing(sym, args, blk)
      @_record << [sym, args, blk]
    end
  end

Now I can take any method I want which takes a parameter and drop the
decoy in:

  def foo(x)
    x.to_s
  end

  d = Decoy.new
  foo(d)
  d._record  #=> [[:to_s, nil, nil]]

In this way we can see what kind of "duck" a parameter requires.

This isn't perfect however because of possible side-effects and
conditionals, which can skew the results. We would require a dry-run
mode and some dynamic means of dealing with condition statements (eg.
a decoy would split down both paths of any condition). It's not an
easy problem, but I don't think it is impossible either --at least not
impractically so.

T.