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

Thaddeus L. Olczyk <[e-mail]> wrote:
:>A precondition asserts a routine's expectations of the state of the
:>world.  A poscondition verifies the results of the operation.  
:>Why do you feel that static typing has *anything* to do with expressing
:>the semantics of an operation in this manner?  I would argue that
:>DBC in a dynamic language gives you the best of both worlds -- some
:>guarantee that you're doing the right thing (the objects you are
:>dealing with honor the semantics you expect, regardless of type), 
:>along with the flexibility of dynamic types.
:
: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.

Well, static type constraints (a better phrase than static typing) on
variables ARE preconditions on the run-time properties of objects (that
the object contained is a descendant of some class or another).

These preconditions have the special property that conformance can
(almost always) be calculated at compile time, whereas for general
preconditions it can't.  And it has the peculiar effect that for
conventional implementations the resulting code tends to go faster. 

Note though that nobody is ever required to write preconditions, and
you can always 'in principle' accept OBJECT or GENERAL for types. 

As I see it the main difference between a dynamic and static language is
not really if you have type constraints on variables or not, but whether
the identity of which *subroutine* is called is itself a run-time
changeable variable.

In other words:   o.method      in Eiffel always calls a routine
called 'method', whose concrete implementation may be in one of any
number of classes---but it still is always called 'method'.

In a generic dynamical language you could do:

		methodvar := ''method''; 
                o.CALL[methodvar](arguments)    --- but nobody uses this syntax
		methodvar2 := frobnicate(methodvar);
		o.CALL[methodvar2](argumetnts); 

The usual consequence is that compile time checking of things is
harder and hence most such languages don't attempt to do it. 

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
*      "To chill, or to pop a cap in my dome, whoomp! there it is."
*                 Hamlet, Fresh Prince of Denmark.