More releases and a long-term plan
December 2007
At about the same time as this column reaches you, EiffelStudio 6.1 will be out. This is another important release which brings many new features. I'll describe
some of them below, but let's first look at the bigger picture.
The release cycle
As you may have noticed by now, EiffelStudio releases are, since 6.0,
organized in a fixed release cycle, every six months. There is the Northern
Spring release, coming out on May 15, and the Southern Spring release on
November 15. This scheme seems to work very well and we are happy that 6.1 is
coming out exactly on time -- even though it had to be developed on a very tight
5-month schedule since the process was initialized with 6.0 released on June 15
rather than May 15. We will continue to stick to this rigorous discipline, which means that any functionality that does not make it to a release is postponed to the
next one, rather than causing a delay. For 6.1 this has been the case for only two significant mechanisms; one of them -- exceptions as objects as per the ISO
standard -- is ready to be integrated and will be part of the very first 6.2 branch, but was not included in 6.1 as it had not been sufficiently tested.
This clock-cycle scheme is (so we are told) good for users, who know what is going to happen and when; this enables them to plan their development
effectively. It is also very good internally for the quality of the development.
Towards full ISO compliance
The International Standards Organization standard for Eiffel (developed in the ECMA TG4 committee) was approved in November 2006, a huge step for the whole
Eiffel community. Ever since the initial drafts of the standard were released, we have heard occasional sneers that this would remain "for the Fiction shelves
at Barnes and Noble", i.e. the new mechanisms would never get implemented. Well, that was fair enough then, but with every new release there is less to laugh
about. In recent releases we have, one by one and without much fanfare implemented scores of these mechanisms; with 6.1 the hardest of all to
implement, attached types, makes its entry. All this is done in full public view; check the Road Map at:
http://dev.eiffel.com/Language_Roadmap
and the more detailed, item-by-item list at:
http://dev.eiffel.com/ECMA_Implementation
to see the progress.
The release plan
The goals for the next four releases are clearly set. The further away the release the greater the potential for adaptation, but we don't expect any radical departure from the overall scheme.
- 6.1 (released 15 November 2007, i.e. now) offers a major advance towards implementation of the ISO-ECMA standard, with important new language mechanisms
addressing fundamental problems, and new environment mechanisms including execution replay. More on those below.
- 6.2 (15 May 2008) will bring new advances in the environment, in particular wizards and new connections to the rest of the world (editors, text processors,
Web tools), enhancing Eiffel's role as a full-life-cycle solution, in particular for requirements and for traceability between various products of a software
project. More generally, significant extensions are planned to the EiffelStudio mechanisms, in particular for refactoring. 6.2 will also introduce performance
improvements -- salient ones we hope -- and define precise benchmarks. The debugger and its execution replay mechanism will be further developed. Perhaps
the most visible effect of 6.2 is the completion of all the important ISO-standard mechanisms. It is the goal of 6.2 to enable you to use the full language as defined by the standard.
- 6.3 (15 November 2008) pursues a different goal. It will not introduce any new functionality but is the Quality release, entirely devoted to correcting as
many of deficiencies and bugs as possible: those known before, and those which we will discover through extensive testing. We feel that with major tasks such
as full ISO Eiffel compliance and dramatic improvements to the environment this will be the time to stop adding features for a while and just make the existing
construction even more solid. 6.3 will also be the time to switch defaults for ISO constructs, as explained next.
- 6.4 (15 May 2009) is only in the initial stages of planning, but we already know that it will have a new profiler and some other tools and architectural
improvements now under discussion. In the next few months we will conduct an extensive user survey to determine what *your* needs and priorities are, so get
ready with your wish lists.
Backward compatibility
In implementing the ISO standard mechanisms, we are coming across cases in which the language specification will cause rejection of some existing programs. In
every case, it's for a good reason: the matter of compatibility was weighed carefully during the committee discussions, and discrepancies introduced only when the committee felt there was a real need for improvement. The compiler haslargely avoided any incompatibility so far, but we are coming to the point where
updating the compiler and the libraries may cause existing code to be rejected. A typical example is attached types: the ISO Eiffel specification guarantees
that you will never get a void call -- a call x.f where x is a void reference. This is a first for any commercially available object-oriented language and, needless to say, will add a major new component to the Eiffel advantage. Now if
one of your programs has a potential void call, maybe because you forgot a precondition "x /= Void" or a test "if x /= Void then ...", the compiler will reject it. Of course this is good, as there was a possible catastrophe lurking
in the code. Still, you want your code to continue compiling until you have had the time to fix the bug. This business of backward compatibility -- as we move
ahead, preserve customers' investment -- occupies much of our discussion time on compiler issues; in fact, it's an obsession. Here is how the forthcoming
releases will address the problem.
In 6.1 and 6.2, any mechanism that could cause an incompatibility for existing code is available on selection of a compiler option; the default option is "no",
that is to say compatibility with Eiffel 3. Updated versions of libraries such as EiffelBase, using the new facilities, will also be available, but again not
the default. This enables you to continue compiling your existing code without any problem, then try out -- cluster by cluster and class by class -- the new
facilities, adapting your code if needed for better safety and expressiveness.
6.3 -- the Quality release, as noted above -- is also the Big Default Switch release. The compatibility mode will still be there, but the default compilation
options will select the new mechanisms for both the compiler and the libraries. Customers have repeatedly told us that breaking changes are acceptable under two
conditions: they must accompany a distinct benefit (and indeed who would not be seduced by, for example, the guarantee of no void calls ever again?); and they
must come in one big swoop, not piecemeal in release after release.
The current release
After this peek into the 18-month future let's come back to today. You are now able to use 6.1, which brings in a number of important innovations.
First, ISO mechanisms. The most important is a first step towards attached types, including the new "Object Test" which replaces assignment attempt, and
automatic detection of many cases where a program can produce a void call. The ISO standard defines a set of CAPs: Certified Attachment Patterns, which
guarantee non-voidness. The compiler performs CAP analysis and will tell you what can be wrong (or will be right). In addition you can, in line with the ISO
specification, declare your entities as "attached" if they should never be void.
Also part of the ISO Eiffel standard is the first implementation of Non-Conforming Inheritance, a variant of inheritance that supports all the general properties of inheritance except polymorphism; this is particularly
useful for reuse and to simplify inheritance hierarchies. Note that the implementation has a limitation: assignment attempt may occasionally give incorrect results on .NET (because the underlying .NET mechanisms do not have
the corresponding notion). This will be corrected for 6.2; since it's a relatively minor problem, and not affecting programs on plain Windows, Unix, Linux etc., we decided to include the mechanism in 6.1 anyway, enabling you to
start trying out the mechanism.
In the environment, the most striking advance is an "Execution Replay" facility in the debugger. Am I the only one to find most current debuggers unacceptably
constraining in their inability to go back in execution (go *really* back, not just pretend to go up the stack but not restore objects)? Cause always precedes
effect: when you find the manifestation of a bug -- say a wrong value, or a crash -- it's always too late to understand what happened. You want to play the
execution backward. That's what you can do in 6.1 for the first time. As you will see, the facility is still partial: it enables you to unroll calls, not other instructions; but it does restore the state of objects (the key facility)
and so should already be quite useful. It also shows the way for the 6.2 version, which will be more sophisticated and should cover all your forward and
backward debugging needs.
The 6.1 debugger also includes other improvements, such as remote object storage and a number of small changes requested by users.
Elsewhere in the environment, you will see a new "Error and Warning Tool" which provides a more convenient way to deal with all the messages that you may get
from the compiler.
Not directly visible, but important for the future -- and visible to anyone interested in the internals of the compiler since, as you know, it's all available in open source -- is an internal restructuring of the environment
designed to make it much easier to add new functionalities. In addition you may of course expect hundreds of small improvements and bug fixes.
Participating
I mentioned the open-source availability of EiffelStudio. This is an opportunity to remind readers of EiffelWorld that the whole technology is ready to be enhanced by creative users. There is no better opportunity out there for
exciting development at the most fundamental level in the software world: a modern, leading-edge environment for producing software. Only with EiffelStudio
can an open-source contributor leverage his or her ideas to benefit an entire community eager to use the best tools -- not just a compiler, but a full solution. Please help us make EiffelStudio even better.
-- Bertrand Meyer |
