Re: Re: Bootstrapping Gobo CVS using Visual Eiffel

Eric Bezault <ericb-D6Qt/9opevxWk0Htik3J/[email protected]>
Newsgroups gmane.comp.lang.eiffel.gobo.general
Organization Gobo
Message-ID <[email protected]>
Roger Browne wrote:
> In principle that's how it should work, but in practise it's going to be
> a rocky ride over the next few years because "directions already
> supported by EiffelStudio" is not always the same as "directions already
> supported by SmartEiffel".

I could have continued supporting both compilers. I proved it
was possible in the past. The problem is that at each single
release SmartEiffel breaks existing code. Even when it was
possible to keep some backward compatility in the compiler.
My feeling is, even though ISE breaks existing code from time
to time, they try to keep existing code working whenever
possible. When they say they will support ECMA, it does not
mean that they won't support existing code which is not ECMA
anymore. If possible they will. I hope! Then they can have
compilation flags to compile strict ECMA or be more permissive.
So will gec. I'm sure ISE don't want to throw away existing
Eiffel libraries. In order to have Eiffel libraries which
work with various Eiffel compilers, we need these compilers
to be permissive. To follow what was written in the TeamEiffel
blog, it is a way to support each others. Visual Eiffel was
a hero doing that in the past to compile (even though a modified
version) of EiffelBase and WEL.

Sticking to a standard (whatever which one is chosen) is not
a good solution in my opinion. It would be if Eiffel was
invented today, but now I think we need tolerant Eiffel
compilers which can compile each others dialects whenever
possible. For example it is possible to support both
`infix' and `alias'. ISE does that, gec as well, and it
allows compiling existing code while migrating to ECMA.
Adding new constructs such as Agents or new classes such
as INTEGER_64 would not break existing code for the users
of a given compiler, but will allow libraries using them
to be used on that compiler. However, removing constructs,
classes or features whithout even any grace time period
like they did in the passed for SmartEiffel (even in the
sake of purity, simplicity, elegence, beauty, ... of the
language) does not help the community, and breaks code of
their users for reasons that is hard to understand for
them.

-- 
Eric Bezault
mailto:ericb-D6Qt/9opevxWk0Htik3J/[email protected]
http://www.gobosoft.com



To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected] 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/gobo-eiffel/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/gobo-eiffel/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.