From: Sean O'Dell <sean@...>
Date: 2004-06-06T09:27:34+09:00
Subject: Re: How to ducktype a Hash?

On Saturday 05 June 2004 12:23, George Ogata wrote:
> "Sean O'Dell" <sean@celsoft.com> writes:
> > The problem isn't that the object doesn't respond to the methods I
> > need, it's that it DOES respond to the methods I need, but the
> > methods don't do what I expect them to do.  In this case,
> > duck-typing simply doesn't work for me.  I found this error through
> > duck-typing, but it existed for weeks before I realized that some
> > objects were quietly trashing sections of data I was passing around,
> > because strings, arrays and others all respond to [] and []=, but
> > DON'T contain objects quite the same way hashes do.
>
> I thought the idea was that if you unit test each piece as you write
> it, these sorts of things are usually caught in time.
>
> > I just don't like this duck-typing business.  I can handle dynamic
> > typing, but I wish there were something more solid about the typing,
> > at least a way to know when an object implements a certain interface
> > or not, so I can tell an array-like object from a hash-like object.
>
> As others have suggested, you don't HAVE to use duck-typing, but if
> you choose that path, you need to provide your own type checks, and
> shove all your classes in the right place in the right heirarchies.
> However, anecdotal evidence (my own and by what others have said here
> before) suggests to me that usually type checks have been weened from
> in favor of a good unit test.  Hence, I imagine, the lack of
> strict-typing facilities in the language.

Unit tests are not the solution.  I don't even do them anymore.  They really, 
really slowed me down and I found I still had just as many bugs to chase 
down.  They never saved me any headaches.

	Sean O'Dell