From: John Carter <john.carter@...>
Date: 2004-05-18T12:06:27+09:00
Subject: Re: How to duck type? - the psychology of static typing in Ruby

On Tue, 18 May 2004, Gavin Sinclair wrote:

> John Carter wrote:
> > Duck typing is an even freer form of polymorphism and in the case of the
> > example I mentioned, with Duck Typing, the geometry library would work
> > on anything that responded to +,-,*,/,==,<, including Vectors and
> > Matrices!
> >
> > I'm hinting at a prime rule of polymorphic / duck typed design. Don't
> > gratuitously constrain the interface. Reusable means you don't know what
> > other types may be fed to you in future, and to be reusable you must
> > allow it.
>
> This is a good guideline for basic types like numbers, strings, arrays,
> etc., because people do tend to create or reuse "similar types" (e.g.
> DBI::Row or whatever it is, instead of Hash) which should "just work" with
> your library.
>
> But as you move away from basic types, through to middle-ground types,
> like an XML document representation, to domain types, like a customer, the
> balance changes.  The prime rule you mention above becomes less and less
> important.

> Now, one step further: an internal application that is never going to
> leave company walls.  A system (involving customers, invoices, and
> payments, say) that is entirely self-contained, and not aimed at reuse at
> all.  In this case, my system is designed to work with XYZ::Customer
> objects, XYZ::Invoice objects, and XYZ::Payment objects.


Hmm. I never _aim_ at reuse, I just don't do anything that would
gratuitously prevent reuse in unexpected manners. Write code that
expects it's output to be the input of some, as yet, unspecified
program.

Do you really need to work with XYZZY::Customer objects, or could your
interface be something much simpler? Perhaps a tuple of numbers? Hey!
Looky I have built graphical output into my program! How?! By making
my output something simple, (tuples instead of XYZZY::Customer) I can
feed it trivially into any graphics package like gnuplot.

If you write things made out of Big Balls of Mud, don't be suprised
when the result glues it self up into an un-reusable Bigger Muddier Ball.

So invoicing passes a big hairy XYZZY::Customer object to Billing,
Billing only uses the name and address, shouldn't you have weakened
the interface so you only pass a name and address to billing instead?

> Furthermore, I may reasonably use some class-checking code at
> strategic points.

So long as ".kind_of?" is just a short cut for a long list of ".respond_to?"'s


> The reason I canvas these examples is to emphasise that isolation (i.e.
> not planning for reusability) is not necessarily a software sin.

Never plan on being resuable.

Plan on being simple.

Plan on being seperable.

Plan on being generous on what you accept and rigorous on what you
deliver.

http://www.catb.org/~esr/writings/taoup/html/
http://www.laputan.org/mud/mud.html

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

The universe is absolutely plastered with the dashed lines exactly one
space long.