Re: Non-philosophical definition of Eiffel?

[Berend de Boer <berend@xsol.com>]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

    Hyman> For those unfamiliar with the concept, Eiffel allows a
    Hyman> derived class to override an inherited method with a method
    Hyman> whiach takes a more restricted argument type. This
    Hyman> obviously causes huge correctness issues, since at any call
    Hyman> using a base object you may be committing a type violation
    Hyman> that you are not even aware of! The Eiffel people have
    Hyman> spent years trying to figure out ways around the problem
    Hyman> while still keeping the original design.

Well:

1. No one needs to use the facility if you don't want it.

2. Contravariance in arguments is not of much practical use.

3. Covariance does not only occur in arguments but in other cases as
   well (generic types).

4. Covariance is of practical use. I think it's a good decision to
   spend time trying to solve it. But if it can't be done, it should
   be removed.

There is a too long paper on this subject:

  http://www.stud.tu-ilmenau.de/~robertw/headings.cgi/~robertw/eiffel/covariance3.htm

  (just read appendix B) 


It seems that the Eiffel world is moving to accept the fact that the
issue must be solved now and that perhaps contravariance must go in
cases where the compiler cannot verify it is used correctly.

There also is a much more elaborate attempt to solve it:

  http://www.inf.ethz.ch/~meyer/ongoing/covariance/recast.pdf

But it seems fairly complex. But for people wanting an introduction to
the issue, this last paper is the one to read.

-- 
Regards,

Berend. (-: