From: Frank Mitchell <frankm@...>
Date: 2000-06-21T09:33:28-07:00
Subject: [ruby-talk:03581] Re: Static Typing( Was: Waffling between Python and Ruby)

Dave Thomas wrote in message ...
>"Frank Mitchell" <frankm@bayarea.net> writes:
>> (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).


Maybe I was misunderstanding the original poster, but he seemed to be
advocating DbC without any notion of types other than "object that responds
to message X".  To state the obvious, if the language has a notion of
interface, protocol, or type, it's merely necessary to check that the object
conforms to that type, at compile-time or run-time, since the contract is
available in the interface/protocol/type definition.  In the database
example, you'd at most have to check that the object "isa" Database (and in
the dynamic cases the integer "isa" Integer).

In the every-message-for-itself case, it would seem to me that you *would*
have to check each argument to make sure it implements all messages your
method expects, and that those messages conform to some required contracts
... otherwise you're open to the problem I mention above.  It doesn't break
encapsulation since it's testing the "interface", but yes it would throw any
hope of performance out the window.  In a way, it was meant as a
reductio-ad-absurdum to true DbC with an insufficient notion of type.

>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.

I bow to your Pragmatism, but DbC is supposed to detect design and code
mismatches, and the biggest mismatch I can think of is objects that don't
implement messages, or implement the name but not the expected external
behavior.  If a language pretends to support DbC but doesn't support that
sort of error, it isn't true DbC.


Frank