From: "David A. Black" <dblack@...>
Date: 2005-01-13T03:15:28+09:00
Subject: Re: Duck Typing as Pattern Matching

Hi --

On Thu, 13 Jan 2005, itsme213 wrote:

> "David A. Black" <dblack@wobblini.net> wrote
>
>>> The first tells me I have to pass in something from which start can be
>>> extracted with [0], and end with [1].
>>
>> I continue not to believe that this can be determined at run time,
>> without essentially doing everything that you'd have to do anyway.
>
> Curiously, that is my point too. If you can some of the things that "you'd
> have to do anyway" in a way that makes more transparent a signature (without
> having to repeat it outside that signature), then that's A Good Thing.
> Patterns like [x,y] are an example of this.

There's a verb missing between "can" and "some" :-)  But in any case,
my point was that there are some things an object can do that you
really cannot discover except by sending a message to the object.
That's what I mean by the things "you'd have to do anyway"; in the
course of establishing by reflection what the object can do, you'd
have to call the method you're looking for -- so why not just skip
that step and call it when you need it?

That was what my example was about.  I think there was some confusion
about which example I was referring to, so let me repeat it:

    class C
      def initialize
        @proxy = []
      end

      def method_missing(*args)
        handle(*args)
      end

      private
      def handle(*args)
        @proxy.send(*args)
      end
    end

Now do:

    c = C.new
    puts c.respond_to?(:[]=)   # false
    c[1] = 2
    puts c[1]                  # 2

In spite of the negative response to respond_to?, the object *does*
know what to do when sent the message []= (and also []).

The point is that in the end, there are cases where the *only* way to
know what an object will do (or not) when you send it a message is to
send it the message.  At that moment, it really doesn't matter how
much build-up there's been, or how many times you've called
#respond_to?, or what the method signature looks like.  There's just
this flashpoint, and its consequences, one way or the other.

> Some other type declarations may not be, unless they do "things you'd have
> to do anyway". Hence my attempts to include variable bindings (which you'd
> have to do anyway) into the type declarations.

I'm just not sold on the idea of a method signature as a place to put
all this information.  Actually it's partly because it isn't "all" --
if you have: def f [x,y]  or whatever, you're giving a clue about one
method that x and y have, but there might be several (or a hundred)
other methods.  It doesn't scale.

But I think the more fundamental problem is qualitative rather than
quantitative: it's not just that it's hard to insert all the
information, but that the "information" available is not, in any case,
really a full profile of the object.  That's why I'd rather just take
objects as they are, and directly query their capabilities
(information relating to their type) only when there's a specific need
to do so.

>> Again, I would describe this as type information, not duck-type
>> information.
>
> Unless the "type information" does the things that you'd "have to do
> anyway", correct?

I personally don't find it useful to call an object's type information
its "duck type information".  At best, it's like adding "statically-
typed" to every reference to a C variable (this method takes a
statically-typed int and a statically-typed pointer to char, and
returns a statically-typed int) -- i.e., redundant.  I also think it
dilutes the meaning, and therefore the power, of the notion of duck
typing.

But honestly, I'm not the duck police :-)  You'll have to use it
however you want.


David

-- 
David A. Black
dblack@wobblini.net