On Sat, 5 Jun 2004, David A. Black wrote:

> I think that could well work in practice, but wouldn't call it duck
> typing.  You're not asking it to quack up front; you're checking its
> module ancestry -- which, I hasten to add, may be exactly what you
> want to do, but isn't the same as what a duck typing approach would
> lead you to.
>
> Let me try to flesh this out with a companion example:
>
>  class UnHashlikeError < Exception
>  end
>
>  module Hashlike
>    alias :get_by_key :[]
>  end
>
>  class Hash           # probably inadvisable, as Paul Brannan has
>    include Hashlike   # recently pointed out...
>  end
>
>  # ...
>
>  value = begin
>            obj.get_by_key(k)
>          rescue NoMethodError
>            raise UnHashlikeError, "Object isn't hashlike"
>          end
>
> or something like that.  The basic idea here is: get your ducks in a
> row, so to speak, by manipulating the object universe so that a
> certain type or subtype of object understands a certain message, then
> at runtime, send that message and branch on the consequences.
>
>
> David

hmmmm... i see where you are coming from, but actualy disagree.  the way i see
it duck typing is really not extremely different from interfaces.  it's
basically just saying 'this thing is a duck if it quacks like a duck'.  in
sean's case he's asking if an object

   quacks (#[])

   like (#[] any_object_not_just_indexes)

   a duck (Hash)

in otherwords he is __exactly__ wanting to know if object posses certain
methods with certain signatures (a #[] methods which takes any 'ol object for
instance).  this is asking if an object implements an interface - albeit a
small one.  in fact duck typing has always struck me as objects implemnting
fine grained (and perhaps dynamic) interfaces.  my approach is simply this:
ruby can't tell me this efficiently now, so, iff all objects can be known
before runtime, i'll simply mark them.  i don't see this as checking ancestry
because one could have easily done this via some other form of marking:

   class Hash
     def is_hashlike?; true; end
   end

   class HashLikeA
     def is_hashlike?; true; end
     ...
   end

   class HashLikeB
     def is_hashlike?; true; end
     ...
   end

etc.

   case obj.respond_to? 'is_hashlike'
     when true
     when false
   end

etc.

in fact.  i can't imagine any efficient form of builtin duck typing which
would not be some sort of aggregate method/signature checking - it's simply
too costly to check each method and signature every time.  but perhaps i'm
wrong...  hopefully in fact ;-)

cheers.

-a
--
===============================================================================
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| A flower falls, even though we love it; and a weed grows, even though we do
| not love it. --Dogen
===============================================================================