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

Thaddeus L. Olczyk wrote in message
<[e-mail]>...
>The reason I say that static typing is a part of DBC is because it is
>the principle contract between an object and it's clients.
>Specifically the contract is that the object responds to certain
>messages, and not to others. This has to be specified before you can
>even begin to talk about what state the object is in before or after
>it is acted on.
>
>Looking closely in OOSE2. I don't see any mention of the relation of
>static typing to DBC. The thing I see is a statement that static
>typing is needed for stable, robust systems. There seems to be an
>implication that static typing has to come as a precondition to DBC.
>
>Any the experts are in comp.lang.eiffel, so I've forwarded it there.

Not an expert ... but think of the types as part of the contract.  That is,
implicit in the contract is the parameter types, i.e. what messages *they*
respond to, and what the contracts of those messages are.  You can define
the contract in terms of the parameters' messages and contracts alone ...
but that could lead to confusion, especially since *those* messages return
objects which have to be defined in terms of *their* messages and contracts,
and so on.  (Down to some "atomic" types, like ints and strings ... but then
we have types again.)

Perhaps the sets of messages will be so small -- set of one -- that the
specification will eventually bottom out naturally.  Most likely, you'll
find repeated sets of messages ... which for the sake of sanity you could
give names, for convenience.

In other words, if there were no types, it would be necessary to invent
them.  Or at least very convenient.  Maybe you could get away with a set of
"standard types" (ints, strings, lists, etc.) and "ad-hoc" types defined by
one or two messages and their contracts ... but you've still got types, and
IMHO it's better to make them explicit.

Frank