Noob question: polymorphic CAT calls in practice
Andrea Taverna
I'm currently looking for a statically-typed OO language with open-
source support and I'm weighing up Eiffel.
I think Eiffell suits nicely, if not perfectly, my needs, however I'm
not comfortable with the CAT call issue.
I think I've understood the theory behind it, after having read the
relevant OOSC chapter and the Recast article; my doubts regard its
practical aspect.
A CAT call may generate a run-time error similar to dereferencing a
void/dangling pointer, since in both cases the program is trying to
access something that doesn't exist. Under this light, a reasonable
way to handle CAT calls at run-time is plain debugging.
The problem comes with 3rdy-party libraries. They can be broken
whenever the client introduces covariance.
Naively, the library author may consider its library as safe a priory
and compile it leaving the job of writing compliant code to the
client.
I'm fine with this solution, but I'm not sure that is enough, there
may be further ramifications for CAT calls that could still break the
code unexpectedly.
More importantly, how eiffel programmers handle this problem in open-
source libraries? Is it possible to have shared libraries in Eiffel?
Are they the norm or the exception?
Finally, which of the solutions proposed in the recast article are in
the current Eiffel standard?
TIA
Andrea
Helmut
Eiffel has the possibility of catcalls, because it allows covariant
redefinitions and polymorphic attachments. There has not yet been
found a language validity rule which allows to rule out catcalls at
compile time.
It is very simple to find examples with catcalls. However these
examples are usually far from being realistic. In realistic setups,
catcalls rarely happen.
A catcall at runtime is handled by good Eiffel compilers as an
exception. A well designed runtime does not allow that execution
continues with the object of the wrong type. Otherwise a catcall would
be very difficult to debug. But with an exception trace it is usually
very easy to see which call with which object of wrong type caused the
catcall.
I agree, that a compile time solution (i.e. static check) would be
better.
The recast proposal is not part of Eiffel and to the best of my
knowledge no Eiffel compiler has implemented recast.
Regards
Helmut
The Eiffel Compiler: http://tecomp.sourceforge.net
http://www.sourceforge.net/projects/tecomp
Andrea Taverna
> exception. A well designed runtime does not allow that execution
> continues with the object of the wrong type. Otherwise a catcall would
> be very difficult to debug. But with an exception trace it is usually
> very easy to see which call with which object of wrong type caused the
> catcall.
I can understand this for the "changed type" part of CAT, since
covariant arguments are anchored, but
what happens with descendant hiding? You would need run-time checks
for every feature access, wouldn't you?
Helmut
The descendant hiding issue has been resolved in the Eiffel standard
(ECMA Eiffel). Descendant hiding is possible only in the case of non-
conformant inheritance. But in the case of non-conformant inheritance
polymorphic attach is not allowed. Therefore this facet of a catcall
is no longer possible. Under conforming inheritance a feature can only
win clients, but not loose clients.
By the way: The runtime checks described above need to be done only if
there is a chance of a catcall (covariant redefinition and polymorphic
attach). The compiler can rule out this possibility in many cases.
From a performance point of view the remaining runtime checks should
not be significant in the majority of the cases.