Hi --

On Thu, 13 Jan 2005, itsme213 wrote:

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

Quite interesting example -- I hadn't seen it.

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

I don't agree that that's a necessary formula, or that nothing that
doesn't fit into it should exist.  A good example is OpenStruct, which
takes advantage of the open-endedness of method_missing.

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

I actually see (a) and (b) as even more distinct than that; or, to put
it another way, I think it's fine to stock respond_to? in cases where
it's possible, but it's not always possible -- precisely because these
two mechanisms are different from each other (not only separate but
different).

(Of course you could just do:

   def respond_to?(m)
     true
   end

to mirror the flexibility of method_missing :-)

>> (Or maybe you just didn't like my code :-)
>
> Even without ever seeing it I am sure it is far better than mine :-)

You did see it -- I meant specifically the "class C" example -- as in,
maybe my lengthy claim that it was not incorrect really isn't to the
point if you just happened to think it was badly written :-)

I think we should probably wind the thread down.  It's been very
interesting indeed, but I think we're starting to circle a bit.


David

-- 
David A. Black
dblack / wobblini.net