Q: how to find all the renamed attributes of a (AST processed) class in the gec compiler ?

[mw66]

Hi,

I want to find all the renamed attributes of a (AST processed) class in the gec compiler:

I have checked et_class.e

and found this navigation:

ET_CLASS.queries: ET_QUERY_LIST

ET_QUERY.is_attribute

but where to find if the attribute is a renamed one?

Thanks.

[mw66]

The essence of that paper is: ECMA Eiffel standard 8.16.2, and 8.6.16 are actually in conflict as demonstrated in this diamond field renaming example:

1) by 8.16.2 “Any two of these features inherited under a different name yield two features of D”, which means replicated (i.e. separated copies) features in the diamond bottom class D; 2) while by 8.6.16 “Semantics: Renaming principle”: “Renaming does not affect the semantics of an inherited feature”, which implies access via separated copies (i.e. via different names in the sub-classes) still end up to the same (shared) inherited feature of the super-classes when applied to the diamond problem of multiple inheritance. (This is how ISE compiler implemented it).

This is why SmartEiffel and GOBO implementations are different from ISE Eiffel: basically ISE did both 1) and 2) (which is wrong); while SmartEiffel and GOBO only did 1) (which is also wrong).

(The correct implementation of 2) while honoring 1) is what have been proposed in the paper; and the ECMA Eiffel standard need to be revised.)

While both the current compiler implementation approaches are wrong, if I have to choose, I'd say ISE's implementation is more wrong: because it also defeats the original purpose of renaming to have separate features. I understand your goal to keep gec work with ISE Eiffel code, but I think if one compiler have to change, that should be the ISE compiler, not the GOBO compiler. NOTE: No matter which compiler will eventually change, this will be a breaking change, will affect (I don't know how) many existing customers' code.

Regardless of the final outcome, a checker to detect the renamed fields in diamond inheritance and give warning messages to the programmers is always needed.

[ebezault]

I'd say ISE's implementation is more wrong: because it also defeats the original purpose of renaming to have separate features.

Are we sure of that? There could be two attributes pointing to the same object.

[ebezault]

From this line:

“Renaming does not affect the semantics of an inherited feature”

you infer that:

which implies access via separated copies (i.e. via different names in the sub-classes) still end up to the same (shared) inherited feature of the super-classes

But "same semantics" does not mean "identifical features", does it?

[mw66]

Are we sure of that? There could be two attributes pointing to the same object.

and

From this line:

“Renaming does not affect the semantics of an inherited feature”

you infer that:

which implies access via separated copies (i.e. via different names in the sub-classes) still end up to the same (shared) inherited feature of the super-classes

But "same semantics" does not mean "identifical features", does it?

This what Bertrand said "ambiguity": it's not made very precise in the ECMA standard what it supposed to mean. And in practice, SmartEiffel and GOBO completely ignored this rule; while ISE compiler implement it as reference identity.

That's how ISE compiler implemented it, you can check and run the example code of RESEARCH_ASSISTANT example.

[ebezault]

That's how ISE compiler implement it, you can check and run the example code of RESEARCH_ASSISTANT example.

This is what I get when compiled with ISE Eiffel:

ResAssis has 3 addresses: <home, dorm, lab>
PERSON  size: 32
STUDENT size: 32
FACULTY size: 32
RESEARCH_ASSISTANT size: 48
ResAssisdo_benchwork in thehome
ResAssis take_rest in the: home
-- print_student|faculty_addr_direct_field
ResAssis as STUDENT.addr: home
ResAssis as FACULTY.addr: home
-- print_student|faculty_addr_via_accessor
ResAssis as STUDENT.addr: home
ResAssis as FACULTY.addr: home
-- check reference identity
ra.addr != ra.faculty_addr
ra.addr != ra.student_addr
ra.student_addr != ra.faculty_addr
-- test some assignment: suppose ra moved both lab2 and dorm2
ResAssis has 3 addresses: <lab2, dorm, lab>
ResAssis has 3 addresses: <dorm2, dorm, lab>

Apparently the RESEARCH_ASSISTANT class has 3 address attributes, not just one.

[mw66]

Apparently the RESEARCH_ASSISTANT class has 3 address attributes, not just one.

Ah? which version of ISE compiler you are using? on Windows? Linux?

here is my result on Linux:

$ ec -version
ISE EiffelStudio version 23.09.10.7341 - linux-x86-64

$ ./app
ResAssis has 3 addresses: <home, home, home>
PERSON  size: 32
STUDENT size: 32
FACULTY size: 32
RESEARCH_ASSISTANT size: 48
ResAssis do_benchwork in the: home
ResAssis take_rest in the: home
-- print_student|faculty_addr_direct_field
ResAssis as STUDENT.addr: home
ResAssis as FACULTY.addr: home
-- print_student|faculty_addr_via_accessor
ResAssis as STUDENT.addr: home
ResAssis as FACULTY.addr: home
-- check reference identity
ra.addr  = ra.faculty_addr
ra.addr  = ra.student_addr
ra.student_addr  = ra.faculty_addr
-- test some assignment: suppose ra moved both lab2 and dorm2
ResAssis has 3 addresses: <lab2, lab2, lab2>
ResAssis has 3 addresses: <dorm2, dorm2, dorm2>

[mw66]

-- test some assignment: suppose ra moved both lab2 and dorm2 ResAssis has 3 addresses: <lab2, dorm, lab> ResAssis has 3 addresses: <dorm2, dorm, lab>

And regardless of 3 or 1 field, these last 2 lines of output are wrong in both GOBO and ISE compiler with respect to the programmer's intended application semantics.

[ebezault]

Ah? which version of ISE compiler you are using? on Windows? Linux?

PS C:\> ec -version
ISE EiffelStudio version 23.09.10.7341 - win64

[mw66]

Ah? which version of ISE compiler you are using? on Windows? Linux?

PS C:\> ec -version
ISE EiffelStudio version 23.09.10.7341 - win64

Are you using this Makefile:

https://github.com/joortcom/eiffel_rename/blob/77ffe635b98256783aca35652995979b8b6bd16b/eiffel_bug/Makefile#L15

and

make ise

Let's try all the different platform and (non-)finalized mode.

[ebezault]

It's in finalized mode. I guess that you are in workbench (i.e. non-finalized mode). It's more likely to be the problem that the different of platform.

[ebezault]

I'm not using any Makefile.

[mw66]

Let's try all the different platform and (non-)finalized mode.

[ebezault]

I get the same output as you in workbench mode under Windows.

[mw66]

OK, I tried, (non-)finalized and finalized mode are different. This is an ISE compiler bug.

[ebezault]

So ISE Eiffel does not agree with itself between workbench and finalized mode! Interesting!

[mw66]

-- test some assignment: suppose ra moved both lab2 and dorm2 ResAssis has 3 addresses: <lab2, dorm, lab> ResAssis has 3 addresses: <dorm2, dorm, lab>

And regardless of 3 or 1 field, these last 2 lines of output are wrong in both GOBO and ISE compiler with respect to the programmer's intended application semantics.

But regardless of which finalized mode, these outputs are all wrong in both GOBO and ISE compiler.

[mw66]

So ISE Eiffel does not agree with itself between workbench and finalized mode! Interesting!

Even ISE Eiffel itself implemented two different field renaming semantics.

[mw66]

So ISE Eiffel does not agree with itself between workbench and finalized mode! Interesting!

Even ISE Eiffel itself implemented two different field renaming semantics.

BTW, @ebezault have you checked your @gobosoft.com email :-)

[ebezault]

BTW, @ebezault have you checked your @gobosoft.com email :-)

Yes, but I still did not have time to review all your work. I have a real job when I'm not playing with Gobo Eiffel! :-)

[mw66]

I'd say ISE's implementation is more wrong: because it also defeats the original purpose of renaming to have separate features.

Are we sure of that? There could be two attributes pointing to the same object.

Now we can read my sentence as: I'd say ISE's workbench mode implementation is more wrong (than the finalized mode): because it also defeats the original purpose of renaming to have separate features.

And it's been proven by their actual output behavior :-)