Hello Helmut,
For the Eiffel system shown at...
http://www.jurjevic.org.uk/programming/eiffel/examples/catcall/Compiled with EiffelStudio 6.2 (x86) I am getting...
D:\Projects\Eiffel\example\skier\EIFGENs\test\W_code>test
Catcall detected in {BOY}.share for arg#1: expected BOY but got GIRL
I am a male and my roommate is a
test: system execution failed.
Following is the set of recorded exceptions:
------------------------------------------------------------------------
-------
Class / Object Routine Nature of exception
Effect
------------------------------------------------------------------------
-------
BOY share @7 Segmentation violation:
<0000000001B00414> Operating system signal.
Exit
------------------------------------------------------------------------
-------
BOY share @7
<0000000001B00414> Routine failure.
Exit
------------------------------------------------------------------------
-------
EXAMPLE make @5
<0000000001B003CC> Routine failure.
Exit
------------------------------------------------------------------------
-------
EXAMPLE root's creation
<0000000001B003CC> Routine failure.
Exit
------------------------------------------------------------------------
-------
It is interesting that it would seem the catcall was detected at runtime
(compilation went with no errors) regardless if I set the "Catcall
detection (experimental)" flag in the project to true or false.
> But the discussion about catcall avoidance has a different focus. The
> catcall shall be detected at compile time in order to have safer code
in
> the binary. So the question is: Can we change the language or the
> language rules a little bit (as little as possible, in order not to
> break much existing code) to make it possible for the compiler to
detect
> catcalls. The change shall not restrict the possibilities of the
> language (or at least restrict it as little as possible) in order to
be
> still useful.
Right, I see, I am afraid that I can't be of much help in this matter.
Some languages restrict that the signature of re-defined feature must be
the same as that of the feature which was re-defined, but this would be
too much of a restriction for Eiffel, I would assume.
For this simple example it should not be so difficult for the compiler
to detect that the actual call...
s.share (g)
will be (at runtime) done on the object of BOY type and therefore issue
a compilation error, but I understand that in general case this can be
very difficult to detect, sometimes even impossible (if the detection
depends on the runtime environment which is unknown at the compile time,
say a polymorphic assignment may be embedded within an if statement
which depends on user input, etc.)
Regards,
Robert Jurjevic
Software Engineer
BridgeHead Software Limited
T: +44 (0)1372 221965 | E:
robert.jurjevic@...
________________________________
From: Helmut Brandl [mailto:
helmut.brandl@...]
Sent: 07 August 2008 14:17
To:
eiffel_software@...
Subject: Re: Covariance / catcall approach -- RE: [eiffel_software]
standardization of ELKS
Hello Robert,
your proposal in a nutshell: Let the runtime find out, if the call is
valid or not.
Actually all compilers I know of (EiffelStudio, SmartEiffel, The Eiffel
Compiler, probably also the Gobo Eiffel compiler) do it that way. The
runtime has access to the actual types, otherwise it would not be able
to do dynamic bind. So a catcall check is straightforward. Is is not
even costly, because it has to be done, only if there is a real danger
of a catcall. So the catcall checking can be compiled in only if
necessary.
But the discussion about catcall avoidance has a different focus. The
catcall shall be detected at compile time in order to have safer code in
the binary. So the question is: Can we change the language or the
language rules a little bit (as little as possible, in order not to
break much existing code) to make it possible for the compiler to detect
catcalls. The change shall not restrict the possibilities of the
language (or at least restrict it as little as possible) in order to be
still useful.
But catcall detection is not a make or break for Eiffel. It is an issue,
but an issue which occurs very very seldom in user code. There are other
runtime errors which cannot be detected at compile time either. E.g.
division by zero just to mention the most prominent.
Hope this helps
Helmut
The Eiffel Compiler:
http://www.sourceforge.net/projects/tecomp<
http://www.sourceforge.net/projects/tecomp>
Documentation:
http://tecomp.sourceforge.net<
http://tecomp.sourceforge.net>
Robert Jurjevic wrote:
> Hello all,
>
> I was not following the discussion but I would like to say something
in
> case it might be of some interest to anybody.
>
> Example in OOSC2 on page 626:
>
> Let BOY and GIRL inherit from SKIER and let all BOY, GIRL and SKIER,
> have `share' feature which takes a single argument `other', in SKIER
> conforming to SKIER, in BOY conforming to BOY and in GIRL conforming
to
> GIRL, and makes `other' a roommate of 'this', that is to say a
roommate
> of a girl can only be a girl (not a boy) and a roommate of a boy can
> only be a boy (not a girl), so if a boy `b' tries to make girl `g' his
> roommate the compiler would not let do it...
>
> s: SKIER; b: BOY; g: GIRL
> !!b; !!g;
> b.share(g) -- compile time error as `g' does not conform to BOY
>
> but a clever boy can do it with...
>
> s: SKIER; b: BOY; g: GIRL
> !!b; !!g;
> s := b
> s.share(g) -- no compile time error
>
> It would appear that the main issue here is the fact that the compiler
> does type checking in "s.share(g)" as if `s' is of SKIER type rather
> than the actual type at runtime (in our example of BOY type).
>
> As it would seem that at compile time it is difficult or even
impossible
> to find out which `share' feature in "s.share(g)" is going to be
called
> at runtime (say we could have a code which does either "s := b" or "s
:=
> g" depending on user input), the solution to this problem could be for
> the compiler to generate preconditions which would check at runtime
> actual types, then the exception would have been risen on call of
> "s.share(g)" as at runtime it was BOY's `share' which was called and
the
> passed argument `g' which was of GIRL type does not conform to BOY.
>
> Example in OOSC2 on page 627
>
> Let KINGFISHER and OSTRICH inherit from BIRD and let KINGFISHER and
BIRD
> have `fly' feature (`fly' feature is not exported in OSTRICH), then
one
> can try make ostrich fly...
>
> b: BIRD; k: KINGFISHER; o: OSTRICH
> !!k; !!o;
> k.fly -- this is OK
> b := o
> b.fly -- no compile time error
>
> Using a similar argument as above the solution to this problem could
be
> for the compiler to generate assertions which would check at runtime
if
> actual method is exported, then the exception would have been risen on
> call of "b.fly" as at runtime `b' was of OSTRICH type which has no
`fly'
> method exported (do not know how current Eiffel implementation deals
> with it).
>
> Regards,
>
> Robert Jurjevic
> Software Engineer
> BridgeHead Software Limited
> T: +44 (0)1372 221965 | E:
robert.jurjevic@...
<mailto:robert.jurjevic%40bridgeheadsoftware.com>
>
_____________________________________________________________________
BridgeHead Software is pleased to confirm this e-mail has been scanned for viruses by MessageLabs.
