From: itsme213 <itsme213@...>
Date: 2005-01-13T08:36:16+09:00
Subject: Re: Duck Typing as Pattern Matching

"David A. Black" <dblack@wobblini.net> wrote in message

> > You should have done:
> > class C
> >    ... your other stuff ...
> >    def respond_to?(x)
> >        x == :[] ? true : super
> >    end
> > end
>
> There's no "should have" here, certainly not based on convention:  I
> don't think I've ever seen a case of adding things to respond_to? like
> that, even in code which makes all sorts of use of method_missing.

Let's see, .... Rails generates lots of "methods" from macros by hooking
into method_missing. Here is the tip of Rail's responds_to chain:

      def respond_to?(method)
        self.class.column_methods_hash[method.to_sym] ||
respond_to_without_attributes?(method)
      end

Not a valid example?

> The whole point of method_missing is that it catches missing methods.

Sure. And if, after catching it, you do something which the (original)
caller would consider a valid handling of the (original) request, then you
should indicate the fact in your 'respond_to?'.  Otoh, if your
method_missing simply interposes some exception stuff, and perhaps then
calls super, then you have not handled the client request. In that case you
did not respond_to the client request.

> You're not expected to enumerate them by name -- in fact, it would be
> impossible (not to mention a maintenance nightmare!) -- and if the
> object thinks it responds to them, then they're not missing.

Imo, this is mixing two very different things.
(a) The Ruby machine rule that if the called method is not found on the
object's [singleton] class, then method_missing is invoked; and
(b) The view that your object's client has of whether or not a message will
be handled (via a respond_to probe), and whether it was handled (via the
outcome of a x.do_it) call.

The distinction is important. I am talking about using (a) while offering a
consistent version of (b). Like Rails does. After not covering that
respond_to ground the first few releases.

> > Pushing that to (an admittedly absurd) extreme, every method would have
a
> > single *args argument.
>
> That's the extreme of a different case actually :-)  I'm talking about
> objects and their responses, nothing about which would lead me to the
> single *args.

My point was that we want our signatures to reveal usage. It's a matter of
degree.
def (x, y, z) # N args
    ... use x, y, z
def [x, y, z] # 1 arg,
    ...use x, y, z
def *args # 1 splat arg, taken 'as it is', queried internally
    x = args[0]
    y = args[1]
    z = args[2]
     ...use x, y, z

> there's no reason to dismiss those things out of
> hand.

No worries, I don't feel about to dismiss any Ruby practices out of hand,
least of all those of clear Ruby experts.

> (Or maybe you just didn't like my code :-)

Even without ever seeing it I am sure it is far better than mine :-)