From: Austin Ziegler <austin@...>
Date: 2003-11-20T17:11:53+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

On Thu, 20 Nov 2003 16:42:15 +0900, Thien Vuong wrote:
> Austin Ziegler wrote:
>> Again: why? Why do you need intrinsic interface validation? [...]
> I'll take a shot here - sorry could not resist.

I'm glad you didn't resist. This, IMO, gets to the heart of the
matter.

> The way it works for me is: what we need is based on a analysis of
> the requirement and the previous experience/learning of how this
> sort of things is done. And that is not based on what language we
> used before although it would probably has some influence. This is
> a decision/intelligent choice.

I'll accept that as a basis.

> It would then be communicated to the team as the guideline on how
> to do it. We then monitor its progress/success/failure and make
> adjustment. If it works well - it got promoted to other groups, or
> even boast about it in comp.lang.ruby (on other thought, maybe not
> :). If not, oh well .... sorry... Who made that damn decision?

This is where TDD would help -- whether or not you're using Ruby.
The work I'm doing in Delphi right now I prototyped in Ruby, but
will be applying to Delphi using DUnit. Indeed, if the requirements
can be defined as unit tests for each unit, then there is a
concrete, *visible* progress for development.

The requirements and design for a Ruby project aren't all that
different from any other project, either.

> Can't wave hand and say we don't need that at all because it is
> the dynamic language Ruby - we can't guarantee anything. It may
> work with some of us (including me), but a non-starter to convince
> others.

Erm. You *can* guarantee things in Ruby, though. If a method
requires a particular behaviour from a parametric object, you can
guarantee that it will fail if it doesn't provide that behaviour :)
Aside from that, if you approach it from the concept of TDD, you get
people to start guaranteeing behaviour.

> Agree that DbC is better for this particular requirement (which is
> only one of an design requirements) - but at this time, I am
> trying to use Ruby, not Eiffel.

1) Ruby does have a simple -- if old and possibly non-working -- DbC
   implementation available.
2) In some ways, unit tests provide DbC capabilities, although they
   are outside of the implementation themselves.

   Look at http://www.rubygarden.org/ruby?FixNumFormat

While this code no longer represents the "state of the art" (see
Gavin's standard extensions project on RubyForge), you'll see a
number of tests there. I will grant that I wrote the tests *after* I
implemented the base code, but I tried to be comprehensive. When I
found weaknesses, I modified the code. Those tests document the code
better than any English document ever could.

-austin
--
austin ziegler    * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
                                         * 03.11.01