Detection of feature availability changes

[marvin_littlewood_426716]

Hello!

If you hide a feature by changing its availability, code outside the
class that calls it, still runs correctly until you compile clean. Is
this deliberate? For an example, consider the initial code for class A:

class A ...
feature {ANY} -- Comment
test: BOOLEAN is ...

and for class B:

class B ...
feature -- Comment
  testing: BOOLEAN is
  local
   anA: A
  do
   create anA
   Result := anA.test
  end

Now change the code for class A to:

class A ...
feature {NONE} -- Comment
test: BOOLEAN is ...

On compiling (F7) after the code change, Eiffel 6.2.7.3753 GPL Edition -
Windows does not spot the problem until you clean and re-compile.

I appreciate that the check will occur before finalizing a project but
wondered if, perhaps, it would be wiser to highlight this kind of
problem earlier in development?

Many thanks for any thoughts...

Mark



[Non-text portions of this message have been removed]

[Emmanuel Stapf]

> If you hide a feature by changing its availability, code outside the
> class that calls it, still runs correctly until you compile clean. Is
> this deliberate? For an example, consider the initial code for class A:

No this should not happen. Could you submit a problem report at
http://support.eiffel.com?

Thanks,
Manu

[Marco Trudel]

Emmanuel Stapf [ES] wrote:
>> If you hide a feature by changing its availability, code outside the
>> class that calls it, still runs correctly until you compile clean.

Actually I always thought that this (clean compilation needed) was a
common issue with EiffelStudio because I frequently run into it. One of
the reasons I remember just now is when background c compilation fails.
Sometimes (often? always?) EiffelStudio then thinks it worked and
executes an old binary acting like it's the new one. But I think I also
ran into it in multiple other situations...

Feel free to add this to your bugreport ;-)


Marco

> Is
>> this deliberate? For an example, consider the initial code for class A:
>
> No this should not happen. Could you submit a problem report at
> http://support.eiffel.com?
>
> Thanks,
> Manu
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Emmanuel Stapf]

> Sometimes (often? always?) EiffelStudio then thinks it worked and
> executes an old binary acting like it's the new one. But I think I also
> ran into it in multiple other situations...

This could happen if you close your EiffelStudio session after a C compilation
error. But not otherwise.

Manu

[Marco Trudel]

Emmanuel Stapf [ES] wrote:
>> Sometimes (often? always?) EiffelStudio then thinks it worked and
>> executes an old binary acting like it's the new one. But I think I also
>> ran into it in multiple other situations...
>
> This could happen if you close your EiffelStudio session after a C compilation
> error. But not otherwise.

I just run into it a couple of times again yesterday (without closing
EiffelStudio). One of the cases where the problem occurs is if you use a
C external that can't be found at linking time. This link error is then
not detected and EiffelStudio thinks the binary has been created
correctly (using Microsoft Visual Studio .NET 2003).
Hitting "compile" again doesn't do anything then since the no code has
been changed and the last compilation "worked". Just the message "Eiffel
Compilation Succeeded" appears in the status line what - obviously - is
wrong.
If I encounter other cases where failed compilations are not detected, I
will report them too. I always assumed this is a known issue since it
happens to me quite often...


Hope that helps
Marco

> Manu
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Emmanuel Stapf]

> C external that can't be found at linking time. This link error is then
> not detected and EiffelStudio thinks the binary has been created
> correctly (using Microsoft Visual Studio .NET 2003).

EiffelStudio should provide a C compiler error entry in the error and warning tool
in all cases. If you can reproduce this in a consistent manner, you could post a
problem report at http://support.eiffel.com and we could organize some shadow
session to see why it would not work properly on your machine.

> Hitting "compile" again doesn't do anything then since the no code has
> been changed and the last compilation "worked". Just the message "Eiffel
> Compilation Succeeded" appears in the status line what - obviously - is
> wrong.

This is confusing indeed. If you have a C compilation error then the C compilation
is unsuccessful while the Eiffel compilation is successful if no errors are found
during the Eiffel compilation. For most people, it is not important if the C
compilation is successful, what is important is to verify that their Eiffel code
is correct (thus the successful message). C compilation only matters when you
actually want to execute your program (agreed this is something you do often), and
if there is no executable file then the environment will prompt you in doing a C
compilation.

Regards,
Manu

[Peter Gummer-2]

Emmanuel Stapf [ES] wrote:
> ... For most people, it is not important if the C compilation is successful,
> what is important is to verify that their Eiffel code is correct
> (thus the successful message)...

I mustn't be "most people" then ;-)

What matters to me is that the whole project builds. That includes C
compilation. The distinction between "Eiffel" and "C" compilation is not
something I think about when I'm compiling. Either the whole thing
works, else it doesn't work.

(There are times, of course, when I'm not too worried that C compilation
has failed. I was recently testing, for example, whether an old
EiffelStudio 6.0 project still compiled in 6.2, but I was missing a 3rd
party C library so of course linking failed. This is one of the few
occasions I can remember when I have considered an unsuccessful
compilation as a "successful Eiffel compilation".)

- Peter Gummer

[Marco Trudel]

Emmanuel Stapf [ES] wrote:
>> C external that can't be found at linking time. This link error is then
>> not detected and EiffelStudio thinks the binary has been created
>> correctly (using Microsoft Visual Studio .NET 2003).
>
> EiffelStudio should provide a C compiler error entry in the error and warning tool
> in all cases. If you can reproduce this in a consistent manner, you could post a
> problem report at http://support.eiffel.com and we could organize some shadow
> session to see why it would not work properly on your machine.

I tried now to create a minimal example but I can't reproduce the
problem with it. But I will soon again work on the real project and
create a bugreport when I run into the issue again. Then I also have
better chances to create a reproducible small test case.

>> Hitting "compile" again doesn't do anything then since the no code has
>> been changed and the last compilation "worked". Just the message "Eiffel
>> Compilation Succeeded" appears in the status line what - obviously - is
>> wrong.
>
> This is confusing indeed. If you have a C compilation error then the C compilation
> is unsuccessful while the Eiffel compilation is successful if no errors are found
> during the Eiffel compilation. For most people, it is not important if the C
> compilation is successful, what is important is to verify that their Eiffel code
> is correct (thus the successful message). C compilation only matters when you
> actually want to execute your program (agreed this is something you do often), and
> if there is no executable file then the environment will prompt you in doing a C
> compilation.

There's exactly the problem: an executable exists already from an
earlier compilation. It will then silently be executed and I wondered
multiple times already why it still showed the same behavior I just
tried to fix ;-)


Marco

> Regards,
> Manu
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[marvin_littlewood_426716]

--- In eiffel_software@..., "Emmanuel Stapf [ES]"
<manus@...> wrote:
>
> > If you hide a feature by changing its availability, code outside the
> > class that calls it, still runs correctly until you compile clean.
Is
> > this deliberate? For an example, consider the initial code for
class A:
>
> No this should not happen. Could you submit a problem report at
> http://support.eiffel.com?
>
> Thanks,
> Manu
>

Dear Manu

Before I do...

I have found the precise circumstances where this occurs. It is when
class A is in a not-precompiled library that is read-only in the
project where class B resides.

Arguably the failure is reasonable behaviour - read-only libraries
should be assumed to be complete and final before using them.

However, I am writing test cases for a library in one project and the
library code in another. I thought that adding the library in read-only
mode would be a reasonable approach, in that it simulates my intended
real world use. On this basis I would argue that if the library code is
not pre-compiled then the the compiler should detect the problem and
report it.

Another way of looking at the issue is to suppose that a library has
changed between versions. Should code reliant on quirks in the old
version still work when using the new? (If the designer deliberately
intended to break old code.)

Am I being unreasonable?

Kind regards

Mark