[ruby-talk:03579] Re: Static Typing( Was: Waffling between Python and Ruby)

"Frank Mitchell" <[e-mail]> writes:

> Hmm ... isn't the whole point of Design By Contract to "fail fast"?
> Checking conformance to an interface lazily would lead to failing in
> the middle of a method where the reason would be less clear, or,
> worse, failing only in a particular branch of an "if" or "case"
> statement.

I don't believe that's the _emphasis_ of Dbc. My reading of Meyer, and
my practical experience, tells me that DbC is a design technique, a
means of expressing the specification of a piece of code and of
guiding the implementation of that code. It's a way of bringing a
design closer to the code, and documenting that design in the code. A
side effect is that you can express that specification in executable
form.

Look at OOSC2 pg 341: "You may decide to treat assertions purely
as comments..".  "In some circumstances (for example testing and
debugging) it will indeed be useful to evaluate assertions; in others
(for example production runs of fully validated systems) you can treat 
them as mere annotations to the software text." (I happen to disagree
with that last point as a generalization)

In the case of the untyped language, I see no realistic way of testing 
that the method will succeed with a given set of input parameters
unless the precondition effectively executes all the code in that
method. Is this a problem? Not in my experience. If it were, I
wouldn't be advocating untyped languages now. But the reality is that
I can't remember the last time that I personally got caught by passing 
an incorrect object in to some method. On of the joys of these
languages is that you can try out your code as you write it, so these
error occur far less frequently than in the more batch-oriented world.

> (I also believe not specifying the *contract* of each involved
> object's methods is a mistake.  On a large-ish Objective-C system I
> worked on we had a few bugs caused by passing the wrong object that
> just happened to implement the right method in the wrong way.
> E.g. "price" as a message to return an attribute vs. "price" as a
> command to initiate an involved calculation with numerous side
> effects which fails because the object isn't in a consistent state.)

So, I'm the routine that writes a value to the database. I'm passed a
database object and an integer. (OK, ignore the design issues here)
You say I should check the contract of the methods of objects I'm
supplied? So every time I write out an integer, I should do a quick
database acceptance test? Sounds like a performance problem to me ;-)
(not to mention a gross breakdown in encapsulation).

This isn't a typed vs. untyped issue. Even in Eiffel, if a method
breaks its class' invariant, you don't know until you've called it. So
the same thing applies. Unless the precondition has some kind of
transactional way of duplicating all the code in a method, it can
never be certain, in Eiffel or in Ruby, that routines called from that
method will succeed.

DbC is not a proof of correctness. It is simply a way of bringing the
design closer to the code, and of checking some aspects of the code
against that design at runtime. Let's not all get too hung up on
trying to push it too far.


Regards


Dave



 ___________________________________________________________________________
| The Pragmatic Programmers, LLC     |  http://www.pragmaticprogrammer.com  |
| Read "The Pragmatic Programmer"    |  www.pragmaticprogrammer.com/ppbook/ |
 ---------------------------------------------------------------------------