From: Nicholas Van Weerdenburg <vanweerd@...>
Date: 2005-01-26T00:56:47+09:00
Subject: Re: "Duck Typing" or "No need for abstract classes"

On Tue, 25 Jan 2005 15:57:32 +0900, Mathieu Bouchard <matju@sympatico.ca> wrote:
> 
> On Tue, 25 Jan 2005, Edgardo Hames wrote:
> 
> > I don't need a Protocol class, the network client should just call the
> > methods of the protocol and duck typing should do all the magic. Am I
> > right? Am I coming a little closer to walking the Ruby Way?
> 
> Ruby allows you to play in the swamp, but it doesn't mean it's better to
> play in the swamp: rather see it as an opportunity to build your own raft,
> hopefully better than the one-size-fits-all raft provided with your
> standard static-language.
> 
> If you want to automate and refactor (DRY/OAOO) your unit-tests to the
> point that a set of unit-tests is shared among all modules-or-classes that
> implement the same protocol, then it's better to encode a hint in your
> program. That hint is to inherit from a dummy module-or-class.
> 
> Furthermore, once you have done that, you have also automated the process
> of adding helper-methods to all modules-or-classes that implement the same
> functionality. Think about how you can add methods to Enumerable and
> Comparable.
> 

My recent thought was that this should emerge as the result of good
programming practice. If you have complexity that requires a protocol,
then there is probably a module that already emerged and fills the
need- e.g. Enumerable, Comparable, IO, etc.

I'm now thinking that explicitly thinking about protocols and
implementing them in a top-down manner is often not so necessary for
this reason. There is a suprising amount of context that a well-writen
program provides on a larger scale. These are harder to indentify then
the problem "how do I know what a represents?" but I think they tend
to emerge.

This explains why rapid Lisp and Smalltalk programmers truly don't
miss explicity-protocols in most cases.  I'm not sure if there are
enough large Ruby programs to  consider this.

Of course, this implies well written programs, which is not the norm
in the world. Which again makes me think of the possible distinction
between pack-programming languages and hacker languages.

And like extreme programming, most early large Ruby programs will be
probably be done by smaller groups of the leading lights of the Ruby
community. That might not generalize well to the world-at-large.

Finally, this implies a bottom-up style of programming, and that is
something of a personal style. So explicity protocols may help people
decompose and think about there program while writing it.

> A small aside regarding Ruby's peculiar multiple-inheritance system: I'd
> rather define a protocol using a non-class module than with a class,
> because then a same class can implement several protocols without
> conflict, as a class can inherit from any number of non-class modules, but
> only from one class, and a non-class module cannot inherit from a class at
> all.
> 
> Those are pragmatic techniques completely consistent with the basic
> principles of pragprog/xp/agile, but for some reason, many among those
> communities have preferred to take a more, er, romantic path.
> 
> Duct-taping as a design philosophy is an obfuscation technique.
> 
> More Canadian Content:
> 
>   http://images.amazon.com/images/P/B00008R9KR.01.LZZZZZZZ.jpg
>


Red Green rocks! Hmmm. I never equated duck typing with duct taping. 
Much to consider...

 
> _____________________________________________________________________
> Mathieu Bouchard -=- Montr�al QC Canada -=- http://artengine.ca/matju
> 
> 

Nick
-- 
Nicholas Van Weerdenburg