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

Static vs. Dynamic typing <> Strong vs. Weak typing vs. no types
VPN
"Frank Mitchell" <[e-mail]> wrote in message
news:8igkjf$ol9$[e-mail]...
>
> 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
>
>
>