From: Rick DeNatale <rick.denatale@...>
Date: 2007-03-03T03:46:56+09:00
Subject: Re: Duck Typing Hash-Like Objects

On 3/1/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>  A few years ago there were some interesting attempts to
> come up with a systematic way to determine an object's type, in the
> sense of its full profile and interface, at any given point in its
> life.  The idea was to be able to get some kind of rich response from
> the object, well beyond what respond_to? and is_a? provide, in order
> to determine whether you'd gotten hold of the type of object you
> needed.  I seem to recall it turned out to be very challenging,
> perhaps impossible, to come up with a complete system for this.  I'm
> not sure if anyone is still working on it.  But it's an interesting
> area.

All of this is personal perspective of course, but my view of duck
typing is that it's really a question of the type of a variable rather
than on objects.  In other words in my view variables have types which
are generated by their usage.  Types in this view are like job
requirements.

So rather than talking about say an array type, to me duck typing is
talking about the type of a variable which is used in a certain way,
which might be somewhat idiosyncratic to the user. Some common such
types do exist, like a queue, a stack, a generalized collection (with
various requirements as to access, ordering etc.)  given one of these,
or a more idiosyncratic type, several objects might work as the value
of the variable in question.

As an example, lets say I'm looking for something to use to drive a
nail.  The obvious 'type' of thing for this job is a hammer, but a
heavy wrench, or a rock can also serve since the usage really just
requires a mass which can be conveniently accelerated so as to impart
inertia to that nail.  If I don't have a hammer to hand, I can press
one of these other objects into service.

In this view of duck typing choosing an object is akin to hiring
someone, you make an initial assessment of whether the potential
employee has the requirements, and if s/he passes that sniff test, you
hire him/her and test that assessment over time.

These kind of types also can require much more than a simple list of
provided interfaces, they also typically rely to one degree or another
on the semantics of those interfaces, often including how the object's
observed behavior is affected by the SEQUENCE of calls.  These types
of types are much harder to statically check. And they cause bugs in
either a statically or dynamically typed system.  In my experience,
the kind of stupid bugs which are flushed out by a static type system
are a small percentage of the bugs which are caused by these semantic
mismatches.

I know that this viewpoint cause conniption fits in folks who believe
in the religion of static type checking, and I've long ago given up
trying to proselytize those with strong convictions.  All I can say is
that I've found such a view of typing combined with a language such as
Ruby which supports it has provided a powerful approach to building
software.

Both static and dynamic typing have benefits and problems, speaking
solely for myself, I just prefer both the benefits and the problems of
dynamically typed systems over those of statically typed ones.

-- 
Rick DeNatale

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