Re: Worth an RCR? static_type_check, polymorphic_type_check, quacks_like

Hi --

On Thu, 6 Dec 2007, John Carter wrote:

> Is there another library like this? I would love it if it were just
> standard methods on Object.
>
> I find this very useful and 'require' it into all code I write. Just
> helps me mop up those problems that static type checking would have
> found for me...

Keep in mind, though, that static type checking isn't just some safety
net that Matz forgot to include in Ruby. The objects are dynamic. You
can't statically check dynamic objects. You can examine their
class/module ancestry, but that only tells you their class/module
ancestry.

> Heres a typical usage, create an object and initialize it with
> stuff. Only much later when you invoke the methods on the object do
> you find you initialized it with the wrong stuff.
>
> Got the parameter order wrong or something. But then the bug isn't on
> the backtrace. So put when you initialize your instance variables you
> can type check'em like so...
>
> eg.
> class MyObject
>  def initialize( _name, _drawable, _theme)
>    @name     = _name.static_type_check String
>    @drawable = _drawable.polymorphic_type_check Drawable
>    @theme    = _theme.quacks_like :border_color, :fill_colour
>  end
>
> ...
>
> end
>
>
>
> # Abstract base class for all the type check exceptions
> class TypeCheckException  < Exception
> end
>
> # This exception is thrown in event of a method being invoked with an
> # object of the wrong duck type.

You can just say "type" here. There's really no such thing as a "duck
type"; "type" already refers to the behaviors of a given object at a
given point in runtime.

> class DuckTypingException < TypeCheckException
> end
>
> # This exception is thrown in event of a method being invoked with a
> # parameter of of the wrong static type.
> class StaticTypeException < TypeCheckException
> end
>
> # This exception is thrown in event of a method being invoked with a
> # parameter of of the wrong polymorphic type.
> class PolymorphicTypeException < TypeCheckException
> end
>
> class Object
>   # Raise a DuckTypingException unless the object responds to all these 
> symbols.

Duck typing isn't just about whether the object responds to a given
message, though. It's really not about the object at all; Dave Thomas,
who introduced the term, describes it as "a way of thinking about
programming in Ruby." (I think I've got that verbatim, or nearly so.)
See also earlier discussions of "hard" and "soft" duck typing, and
Rick DeNatale's concept of "chicken typing".

I don't want to recapitulate the thousands (literally, I believe) of
posts to this and other lists about class/module-checking in Ruby, but
my two biggest problems with it are:

   1. it doesn't work, because Ruby objects are not constrained by
      their ancestry;
   2. it tends to be the tail wagging the dog, in the sense that it
      leads to (or sometimes comes from) the conviction that having
      objects that don't behave exactly like freshly-minted objects
      of their class must be bad, when it's actually engineered
      as a basic principle into the language.


David

-- 
Upcoming training by David A. Black/Ruby Power and Light, LLC:
    * Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details and 2008 announcements!