search

gobo-eiffel / gobo

The Gobo Eiffel Project provides the Eiffel community with free and portable Eiffel tools and libraries.
https://sourceforge.net/projects/gobo-eiffel/
Other
59 stars 24 forks source link

Q: is it a real flaw in the Eiffel's renaming mechanism in this diamond problem? #66

Open joortcom opened 1 year ago

joortcom commented 1 year ago

@ebezault

Hi Eric,

I'd like hear what you think of this paper:

https://github.com/joortcom/eiffel_rename

https://github.com/joortcom/eiffel_rename/blob/main/eiffel_rename.pdf

1) is it a real flaw in the Eiffel's renaming mechanism in this diamond problem? 2) how does the proposed fix sounds to you?

I'd really appreciated it if you can tell me your thoughts.

Thanks.

mw66 commented 6 months ago

@ebezault I saw you self-assigned this issue, so what do you think of the problem reported in the paper? mind to share?

ebezault commented 6 months ago

I did not read the paper yet. It's on my TODO list for the coming weeks. I'm sorry I did not look at this issue before. I was not able to work on the Gobo project in 2023 due to professional workload. I do remember that ECMA now disables diamonds (and hence the problem which comes with it) by allowing only one conforming inheritance path (the other inheritance paths should be non-conforming). But I have to read the paper and dive into ECMA standard again to give a more thorough answer. As far as I know no Eiffel compiler supports this new rule from the ECMA standard because it would break existing code.

mw66 commented 6 months ago

ECMA now disables diamonds

Oh, when it happened? I didn't see this in the ECMA 2006.

Any open new ECMA documents update (even draft) or discussion forums I can take a look?

Thanks.

ebezault commented 5 months ago

I did a quick search, but was not able to find it. I'll come back to you on this after I read the paper and looked deeper in the ECMA documents.

ebezault commented 5 months ago

OK, my memory was wrong. I found some old notes from ECMA standardization meetings (see below). In the draft of standard before its first edition, the select clause had been removed, and only one conforming inheritance path was allowed in case of repeated inheritance. The committee decided to reject this rule before the first edition:

Select clause (section 15.5, page 325): The team decided to keep select and still have nonconforming inheritance because the two mechanisms address different needs. Keeping select allows having two or more conforming paths whenever needed.

The section and page number are from the draft version. I think that it relates to the rule VMRC (8.16.10 page 94) in the second edition of the standard.

Sorry for the confusion. I still need to read your paper though (I guess that it's your paper, because the github login ids are different).