"David A. Black" <dblack / wobblini.net> wrote
> > Curiously, that is my point too. If you can some of the things that
"you'd

Darn! "If you can DO some of the things ..."

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

Simple. To make the signatures more revealing (to human eyes or code),
provided that:

- you don't have to re-do the things (e.g. establish bindings) in the
signature,  or

- there are performance advantages to the info (e.g. type-optimized code
paths), or

- there are other advantages to the info (e.g. certain reflective
facilities)

>     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 []).

Fine. So you have implemented method_missing and respond_to? in mutually
inconsistent ways. But then this is possible in any number of other places
in Ruby where sets of methods are expected to be mutually consistent, but
that is up to the programmer.

You should have done:
class C
    ... your other stuff ...
    def respond_to?(x)
        x == :[] ? true : super
    end
end

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

Pushing that to (an admittedly absurd) extreme, every method would have a
single *args argument. No, seriously, I do understand and respect your
viewpoint. But some of your examples justifying it are not quite correct
(like your class C).

Cheers.