NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/eiffel/1379

Internet Message Format | 1992-12-17 | 1.9 KB

Path: sparky!uunet!plsparc!lef
From: [e-mail] (Lawrence E. Fitzpatrick)
Newsgroups: comp.lang.eiffel
Subject: Re: Semantics of invariants
Message-ID: <[e-mail]>
Date: 17 Dec 92 06:28:09 GMT
References: <[e-mail]>
Organization: Personal Library Software, Inc.
Lines: 36

In article <[e-mail]> [e-mail] (Richard Bielak) writes:
>Is the invariant supposed to be true *ALL* the time, once the object is
>created?
>

This is rather elegantly defined in the E3 book (p126):

    The invariant specifies properties which any instance of the
    class must satisfy at every instant at which the instance is
    observable by clients.

A simple reading would suggest that in a single threaded executable,
"observable" might be interpreted to mean "when the thread of control is
with the client."  On the other hand, that approach makes some assumptions
that may be invalidated sooner than one might like.  [Remember the
Macintosh and "32-bit clean".  Apple did say, don't do this, but there
wasn't any penalty at the time!]  I would prefer a more abstract reading.

>If this is so, you can imagine each object having an "invariant-checker"
>running continously on another processor.

Interesting idea, depending on what it does.  Seems that the only time
you need to check invariants is when a state changes.  The cost of
checking it (in some cases) far exceeds the cost of signalling a checker
to check it.  (something about dependency lists springs to mind).  But
then there are the synchronization problems -- by the time the checker
determines a violation, the code being checked has executed another 3
million instructions!

What percentage of a program's operations are instance state changes?
I bet it's not as high as one might think (for most things).
--
Regards, lef

Lawrence Fitzpatrick                    Voice:[phone]/Fax:[phone]
Personal Library Software               [e-mail]