--- Comment #85 from Andrei Alexandrescu <and...@metalanguage.com> 2012-09-05
07:26:07 PDT ---
I've had the opportunity to discuss the matter with Bertrand Meyer himself and
with a graduate student of his. Bertrand didn't have a defined answer offhand,
but opined that the static contract should be evaluated. His book says the same
Julian Tschannen (who allowed me to share his name here) wrote me the
1. Eiffel ECMA standard (, Rule 8.23.26) says, that the contract of
the dynamic type is checked, i.e. "pre_A OR ELSE pre_B"
(combined precondition, , Rule 8.10.5).
2. The Eiffel runtime does actually that, first checks the
precondition of the parent class A, and then the precondition
of the subclass B.
My take on the issue:
Dynamically it runs of course without a problem. If you would have a
static checker (e.g. the AutoProof tool that I am developing), the
code would be rejected due to the static check. Since we strive to get
a language that is statically checked and fully verified, it would
probably make more sense to just check the precondition of the static
type and not take the dynamic type into account for precondition
checks, since the client code works just with the given example and is
not correct for all possible arguments.
Or to be more precise, you could take all the static information into
account, but only the static information. It would for example be
possible that the client code has some precondition that would make
sure that the code is statically correct, even if the call - when
looked at in isolation - is statically not correct.
So we currently do what the Eiffel standard and compiler do, but not what would
probably be the most sensible thing. In my opinion we should do the right thing
and check the contract statically.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------