[MUD-Dev] Object Models

[John Buehler]

Miroslav Silovic writes:

> > Fortunately, it is not MY basic assumption that the construction
> > paradigm is edit/compile/etc.  The primary requirement for system
> > construction using the techniques that I learned is strong typing.
> > Thus precise contracts, etc.  The reason that dynamic systems are a
> > bear is because you have to know how to construct and implement
> > contracts on the fly.
>
> I disagree with this. I have never heard about a system that can
> verify pre/postconditions, loop invariants and class invariants by
> static code analisys, and without this capability, contracts in
> themselves aren't much help (correct me if you in fact do use such a
> system).
>
> Without this, runtime typechecking is not much worse than compile-time
> typechecking - and some systems can convert any arbitrary predicate
> into a type.

To me, runtime type checking implies the possibility of a piece of code
getting its hands on a component that is supposed to be type A, but in fact
it is type B.  Static type checking is intended to ensure that this
situation does not take place because the component is known to be type B
and, therefore, cannot be passed to the code which has declared itself to
accept only type A components.

Your mention of verification of pre- and post-conditions, class invariants
and such suggests to me that you consider this to be related to type
checking.  It is, after a fashion, but we were doing those things up front.
So we would define precise contracts, implement components and then verify
those components against those contracts by actually running the component
exhaustively and verifying that the contracts were adhered to.  Once that
process is completed, the component is declared to be of type X and is
shipped.

I'm not sure how that fits into your dynamic versus static type checking
nomenclature.

> Whenever I use strong typing, I'm left with an impression that I spend
> lots of effort declaring things for VERY little gain - this is because
> most of my errors end up having nothing to do with anything that can
> be statically checked.

This really throws me a curve.  What errors are we talking about?  Type
means contract and contract means behavior.  So if I know what behavior I
can expect of a component, I should have very few errors.  The only errors
that we were really faced with were those due to physical resource problems.
The only components that needed to report an error were the ones that
allocated resources: memory managers, network connection managers and the
like.  Other than that, we coded with the assumption that everything would
work.  This assumes, of course, that preconditions are met, which is the
responsibility of the client.

JB


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev