liberty-eiffel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Noob First Post


From: Paolo Redaelli
Subject: Re: Noob First Post
Date: Sun, 28 Nov 2021 22:09:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

Il 28/11/21 21:57, Raphael Mack ha scritto:
Am Samstag, dem 27.11.2021 um 14:07 +0100 schrieb Eric Bezault:
Fixed formatting issue in my previous message:

On 27/11/2021 11:44, Paolo Redaelli wrote:
  > And adding GTK support

Note that there is already support for GTK in EiffelVision2
(https://github.com/EiffelSoftware/libraries/tree/master/Src/library/vision2/implementation/gtk3
).
So what would be nice is if Liberty Eiffel could support the
ECMA Eiffel dialect, or at least the parts that are often used
in third party Eiffel libraries. It would be so nice to be able
to use Eiffel libraries that already exist out there without
having to worry about what Eiffel compiler we use. This would
avoid duplicating the work and focus on new Eiffel libraries and
tools which are still missing.
In my eyes there are great features in ECMA (like dynamic type
conversion) which make Eiffel a bit more handy, while - on the other
side - I loved Eiffel especially because you know well what's going on
in your code. With convert simple-looking assignments could do a lot of
magic with hard to see side effects. With quite some experience in
safety related low level programming I always dreamed to see Eiffel in
this area and there it would be a nightmare to allow a simple
assignment to consume additional memory...
I was mumbling too about convert. My idea was to add three compiler switches: --silent-convertions, --convertions-are-warning, --convertions-are-errors. Those may cover most use cases.

With that in mind I would have always tried to push towards supporting
new features in an "ECMA mode" while not using these in the core
library and supporting a conservative mode. But for sure, as soon as we
talk about GUIs with GTK or alike I see no issue with requiring the
modern stuff :-)

According to https://wiki.liberty-eiffel.org/index.php/ECMA which document the work of Raphael and Cyril the languages doesn't look so different these days.

Let's start with the easy one: why ISE chose the "inherit {NONE}" syntax for non-conforming inheritance?

I mean the first question it will raise could be "so can I write inherit {FOO} to limit conformity to type FOO?"

I can't find a rationale behind "inherit {NONE}" but I will gladly read an explanation...





reply via email to

[Prev in Thread] Current Thread [Next in Thread]