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/