From: patrick-may@... (Patrick May)
Date: 2002-09-14T18:25:17+09:00
Subject: Re: not grasping the method overloading/multi-dispatch thing

Paul Brannan <pbrannan@atdesk.com> wrote in message news:<20020913102550.C25425@atdesk.com>...
> On Fri, Sep 13, 2002 at 01:22:16PM +0900, Patrick May wrote:
> > # asserts
> > anArray.assert_includes( anotherArray )
> 
> Why should this be in the Array class?  What's wrong with:
> 
>   Assert.assert_includes(anArray, anotherArray)

anArray.assert_includes( anotherArray ) was an array specific assert
that raised a helpful array-specific error message.  It would say
something like 'expected[3] => "foo" not found.'

The class-specific semantics combined with a chance to reduce the
number of args led us to use that method.  We had a similar, but
different method for hashes.

> (same goes for most of the other examples; they really don't belong in
> the classes you've placed them).
> 
> > # formating
> > aString.to_title_widget
> 
> Is this widget a Fox widget or a QT widget?  What happens if two
> programmers both write a to_title_widget method, one that creates a QT
> widget and another that creates a Fox widget?  One programmer's code is
> likely to break.

In a given application, you could safely make an assumption that the
widget matched the graphics library that the rest of the app used :-)

I give such examples b/c aString.to_title_widget will never be in a
standard api, but it's very useful to be able to add it if needed.

~ Patrick

P.S. I think that object.diff( other ), returning a text description
of difference, could be a great pattern with Test::Unit.  A problem
with large strings or arrays is hunting for the difference in the
failure message.  Object.diff gives assert_equals a place to get a
class specific comparison message.