From: gabriele renzi <surrender_it@...1.vip.ukl.yahoo.com>
Date: 2004-06-08T18:08:39+09:00
Subject: Re: How to ducktype a Hash?

il Mon, 7 Jun 2004 01:53:41 +0900, James Britt
<jamesUNDERBARb@neurogami.com> ha scritto::

>
>This is an important point.  Earlier in this thread there was a comment 
>along the lines of, "If Ruby was built for duck typing, why weren't the 
>standard libs better designed to manage the quirky cases?"  It struck me 
>as an odd, and misguided, question, because duck typing is more of an 
>epiphenomenon.  It's not a target of the language design, it's just one 
>of the things you get as a result.

I wonder if that was my message. 
Please let me explain my opinion[1].

Duck Type happens. 

I completely agree. But what I see is that the basic building blocks
of it (let's call it basic building quacks, BBQ sounds fine :) 
are: some interfaces are common, we can rely on them. 
That is true for, say, #read() , for #each(), for #[Object]=o and so
on. 


I suggested having a mix-in for , say, Input-like objects. 
This is useful, imo, for two reasons:
 it let's you build Input-like objects programmatically
 it let's you strongly specify they're interface[2].

Why there are *so much* enumerables out there and *so few*
IO objects ? Because a mix-in let's you easily create an enumerable
class, a class that is easy to use (working with a given interface)
and affordable (we can expect that #each will work as expected, and to
have #find_all and so on)
OTOH, we can't expect from an object that has #[]= to behave like an
hash, neither via #[]= neither via #keys or something else.

Having more mix-in is not saying 'ruby should have been designed for
it'. 
It is just: now we have lots of objects that may take advantage of ,
say, a Map mix-in (PStore, dbm, rbtree and so on), could we refactor
the stdlib to allow them to use one single interface avoiding little
problems like a missing method or a wrong number of parameters?

Just as a side note, this solves the problem of interface checking.
It solves the problem where it's more needed instead of a general
solution[3]: the place where you want to check an interface you're
probably using a common anonymous interface anyway, and in the other
places you could, if you want, use the "kludgy trick" of adding a
useless tag-module.

If you're thinking that in your own library you make extensive use of
a given interface without declaring it (say, PDF::Writer with
#hyphenate() ) you could: 
 declare it (include Hyphenable)
 ignore the problem, when needed someone could add the tag anyway


just my 2 cent, and I need some cappheine.


[1]
yes, like many other people I want to use matz to implement my
language. It is  our right as user to do so, and it is his right as
the project leader to just forget us :) When I'll write my own
language...
[2]
strongly as in 'easy to check'. Lies are ok, I don't think that any of
the proponents of any kind of type checking in ruby wants full
checking, *just something* is ok. 
[3]
and everybody will stand up 'we wnt general solutions!". Not all we
do. A simple solution for the most part of a problem may be better
than a convoluted solution for everything.