Re: Worth an RCR? static_type_check, polymorphic_type_check,

On Dec 7, 7:09 am, Rick DeNatale <[e-mail]> wrote:
> On 12/6/07, Robert Dober <[e-mail]> wrote:
>
>
>
> > On Dec 6, 2007 9:22 PM, David A. Black <[e-mail]> 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 Rubyhttp://talklikeaduck.denhaven2.com/

That's also a great use case for what I was talking about in my last
post. ;) An #arity < 1 check might be nicely used in such a case to
check whether to call #save with an argument, and if not, do something
else, rather than letting the exception raise, catching it, then doing
something else. Either way works (though catching the exception is
probably less efficient, because an exception object has to be
instantiated and the rescue machinery has to run); but in cases like
that, it makes perfect sense to do "validation" on the object. (Even
if it arities like a chicken right now...it's still really a duck ;P)

Regards,
Jordan