From: Rick DeNatale <rick.denatale@...>
Date: 2007-12-07T22:09:58+09:00
Subject: Re: Worth an RCR? static_type_check, polymorphic_type_check,

On 12/6/07, Robert Dober <robert.dober@gmail.com> wrote:
> On Dec 6, 2007 9:22 PM, David A. Black <dblack@rubypal.com> wrote:
> > On Fri, 7 Dec 2007, Stefan Rusterholz wrote:
> > > Robert Klemme wrote:
> > >> 2. point in time is not the only difference as you have pointed out
> > >> (method_missing).
> > > While I mostly agree with what you say: if somebody defines
> > > method_missing, he should update respond_to? accordingly. Anything else
> > > I'd consider a bug.
> >
> > You might want to file a bug report against the standard library:
> >
> > >> require 'ostruct'
> > => true
> > >> os = OpenStruct.new
> > => #<OpenStruct>
> > >> os.respond_to?(:"a=")
> > => false
> > >> os.a = 1
> > => 1
> >
> > :-) I think it all depends on exactly what you're doing with
> > method_missing. In general, I tend to see it the other way around:
> > respond_to? tells you what the object's current knowledge of its
> > messages is, while method_missing is specifically a handler for
> > messages the object does *not* respond to. In the end, it can be done
> > either way, and probably should be, in different situations. I
> > wouldn't say that either approach is inherently buggy.

> I believe that it is naive to think one could update responds_to?
> dynamically when implementing method_missing, just think about the
> following implementation:
>
> def method_missing name, *args, &blk
>    super if random(42) > 20
>    42
> end
>
> would you like respond_to?( :something ) to return :maybe ?

While this last example might strike some, heck even me, as silly, it
is evidence of how Ruby 'types' are dynamic in multiple dimensions.

* Time
* Instance by instance, with the 'class' held constant.
* State of the instance, with the 'class' held constant.

I came across another interesting example from ActiveRecord, as I was
reading myself to sleep early this AM with "The Ruby Way."

There's a method ActiveRecord::Base#save which is used to, surprise,
save/update an AR model instance to the database.  This method is
documented as taking no arguments.

BUT

Under some circumstances, you can call the method with an optional
argument as in:

    book.save(false)

Which causes the object to be saved bypassing any validation callbacks.

It turns out that the save method will only take the argument if the
model has one or more validations specified.  The method signature
changes dynamically.

While I can see these kind of things frustrating, or even angering
chicken typers, the are the very things which make Ruby magical.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/