Re: Real OO

[bobduff@world.std.com (Robert A Duff)]

In article <4kbqun$iiv@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>Some possible answers: 
>
>(a) It is impossible to write a routine that has such expectations.
>    [If so, Eiffel is less flexible than Ada.]
>(b) The Eiffel translator magically deduces an algorithm for
>    Corresponding_Parts_Equal that works for the two dynamic types in
>    question.
>    [If so, we can stop this discussion now, I'm sold on Eiffel!]
>(c) A run-time error results immediately.
>    [If so, no different from Ada.]
>(d) The version of Corresponding_Parts_Equal for the dynamic type of A is
>    invoked with a parameter that does not have the expected dynamic
>    type.  Depending on the algorithm for that version of the routine,
>    this may lead indirectly to a run-time error later, or fortuitously
>    happen to give the right answer (at least for all the cases we tested
>    so far ;-) ), or give an incorrect answer masquerading as a correct
>    answer.
>    [In any of these cases, Ada is more robust.]

Norm, you didn't mention (e), something is done at link time.

In Eiffel, there's something called "system validity check" or "system
goodness check" or some such thing (I can't remember what it's called).
It checks, at link time, certain things that *seem* to be holes in the
type system, if one is used to thinking only about compile time.

>Please enlighten us.

Yes, please, perhaps our friends in comp.lang.eiffel would like to
enlighten us about system (whatever) checks.  Also, Eiffel compilers,
unlike Ada compilers, typically support incremental compilation.  How
does this fit in?  Does "link time" disappear, because it's all
incremental?  How does the system goodness check affect the ability to
re-use stuff?

- Bob