Hi --

On Wed, 30 May 2007, Maurice Gladwell wrote:

> James Gray wrote:
>> On May 30, 2007, at 7:53 AM, dblack / wobblini.net wrote:
>>
>>> You could of course shoehorn find_by_* into respond_to? for AR
>>> objects, if you don't mind, essentially, writing method_missing twice
>>> (once for real, once as a kind of pseudo-static twin).
>>
>> I don't really understand this stance.  My opinion is that providing
>> a method_missing() implementation is a convenient way for a
>> programmer to define a lot of dynamic methods.  This increases the
>> messages an object responds to.
>
> I must agree with James Edward Gray here.
>
> David's contrived example is of course possible, but highly unlikely in
> practice; a programmer will generally not code his program into a
> situation in which he can't be sure whether an object will respond to a
> particular message sent to it. That's probably a major reason for having
> Object#respond_to?.

But it can happen; hence NoMethodError.

> In practice, and certainly in the Rails' find_by_* case, you have a
> well-defined  range of messages to which an object will respond, known
> already at development time. I don't know of a single real-life example
> in which a programmer doesn't know at development time the entire range
> of messages his objects might respond to. And Rails - with all its magic
> - notwithstanding.

If it's absolutely known what messages every object will respond to,
then we don't need #respond_to? :-)  I don't know... it's obviously
just a slightly different way of looking at it.  I'm uneasy with
having to rewrite respond_to? every time I implement method_missing;
it seems like a lot of work and an awfully tight coupling.


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)