Team Eiffel

EiffelStudio 5.7.64493 (changelog) has been released as "EiffelStudio 5.7 Final".

Downloads are available for FreeBSD x86, Irix MIPS, Linux (PPC, Sparc, x86 32 bit, x86 64 bit), OpenBSD x86, Solaris (Sparc and x86, 32 and 64 bit), Windows (32 and 64 bit). There is also a PorterPackage that can be used to bootstrap EiffelStudio on other platforms.

Downloads will also be available from eiffel.com in a few days.

Labels: eiffelstudio

Yesterday, i had the surprise to discover that the keyword unique has deappeared! Hmm, well, lastly it disappeared from the Eiffel language of ECMA.

There are many good reasons to remove that keyword.

• there is no way to have coercition to the defined subset by the language except by putting in many contracts that x.in_range(my_first,my_last)
• there is no way to specify a mapping to a given numeric sequence (ex: as in C, to tell the value of the first, the remaining being set with increments of one) what can be usefull in cases
• where mapping the first element to zero has good algorithmic properties
• where a same integer can receive values of 2 or more not overlapping series, but:
  
• compilers are free to make sequences that overlap (for example all the sequences begin with zero), then,
  
• the consistancy of select have to be checked: when a unique feature appears in some expression of the when clause, all the expressions in all when clauses of the select must be features of the same uniqe list.
  

So who will regret a so weird keyword?

Frankly, me! I will regret it a lot, because in spite of all these disavantages, I made use of it often and regularly.



And now? What to do for my programs that after 200 lines of features enumeration just say: INTEGER is unique? Well for it, I have a good solution. Because they are generated by some scripts, I would update these scripts if in one hypothetical day I have to program for ECMA eiffel.

And for my day to day programming where I need few features in the list? Okay I will use my delicate fingers on all these unpleasant keys to enter explicitly the type and the value. Does somebody have a better idea for a lazy man?

Forms in EJAX are either the normal HTML controls or XForms controls. The former can of course be created by any designer, the latter will probably need a programmer with an HTML editor. XForms controls are translated to HTML controls through the final pass with ejax_page_formatter.xsl.

To display controls with data in it, an application could create HTML output with controls with value statements. But that violates the EJAX principle of separation of concerns: HTML code should be separate from data as much as feasible.

This problem is solved within XForms as well. The idea is to bind controls, through an XPath statement, to an instance. When the EJAX page formatter style sheet formats an HTML page, it basically copies the HTML nodes to the output. And does something special in certain cases. If the HTML control has an id element, the page formatter checks to see if there is a response with the same id as the form (and with type = 'model') and if the contents is an XForms model. If so, it will check if this model as a bind statement with an id equal to the id of the control. If so, it will use the specified XPath statement to select the data from the also supplied xforms:instance element.

EJAX also has support for other attributes that can be specified with an xforms:bind element such as if the control should be readonly. If so, it sets the readonly attribute.

It would be much easier of course if all browsers would support XForms out of the box. This probably won't happen. So XForms has to be emulated somehow. It is probably possible to emulate XForms with JavaScript, but that might lead to significant initial download times as also an XSL JavaScript implementation has to be provided. So EJAX emulates XForms as much as possible at the server side, emitting pure HTML as output.

And we end up with a system where we have achieved separation of concerns: the HTML can be maintained and touched outside the hand of programmers (within certain limitations of course), and the HTML is connected to the data by passing in an instance with the XML representation of the data and the bind statements to select the appropriate values from this instance.

Read three interesting articles in a week. That's not bad. The first was "A Study of Design Characteristics in Evolving Software Using Stability as a Criterion", in IEEE Transactions on Software Engineering, May 2006 (yes, I'm behind sometimes).

A study of software that has been in use, and has significantly evolved for three decades. What is still the same, and what has changed? The example has some Fortran specific bits in it, but this was a pretty interesting and unique article.

Then we had Componentization: The Visitor Example. By our own Bertrand Meyer and Mrs Bezault.

A really bad article was "Designing for Recovery". Can people please, please read OOSC2 and what Eiffel's view on exception handling is? This article was absolutely confusing because of the absence of clear definitions.

And did you know that Knuth's volume four has been published? Found out why this has been kept secret in "The Atrocity Archives" by Charles Stross.

This is a followup to a series of previous posts; the previous one was The Zen of Python - Part II and the introduction is at The Zen of Python - Part I. If you are lazy to read that introduction, this is about some Python design principles analyzed from an Eiffel perspective and comparing it with other languages (specially Python itself).

Simple is better than complex.

Simplicity is one of the most shining aspects of Eiffel. It lacks several features present in other languages, providing instead a few consistent but powerful ones that solve several problems together. For example, the Eiffel "class" concept serves also as a "module" concept (present in other languages as a separate thing). There are no functions and methods, everything is a class feature. Access routines and attributes are slightly different concepts in some cases, but for most purposes they are just "queries". Eiffel inheritance serves the purpose that other languages solve with inheritance, module importing, interfaces, mixins and a plethora of other constructs.

The nice thing is that most of this concepts are powerful but still follow simple and easy to understand rules. They are not swiss-army chainsaws, they are tools that simple adapt to several tasks, making the user unaware that they are actually different tasks.

One of the examples of this is the way that multiple inheritance (MI) works in Eiffel. The possibility of using MI is one of the things that make Eiffel inheritance so powerful. However, among other languages with MI, Eiffel has some of the simplest rules available, thanks to the properties of "one name, one feature", symmetrical inheritance (the parents of a class have no "order") and explicit conflict solving. Compare this with languages which use the C3 method resolution order; C3 has nice mathematical properties, but gets a little hard to explain. So most developers of these languages (I have informally polled several python developers), don't know
actually how their MI works. It is hard to understand intuitively what will happen in a class hierararchy with heavy use of MI and repeated inheritance; the Eiffel library has a lot of that and still method resolution is simple (I would dare saying obvious) to understand.

Complex is better than complicated

This is one of my favourite points in "The Zen of Python". Although "simple is better than complex" is easy to defend, there is always a limit about how much simplification you can add to a language without forcing the developer to workaround the "simple" mechanism, creating code that is actually more complex than the complexity that would have been added by a new language mechanism. As Albert Einstein used to say "Make everything as simple as possible, but not simpler".

I find an example of this in the ability of having multiple constructors in Eiffel. It sure is "simpler" to do as most other popular languages (C++, Java, Python) and offer a single constructor in each class; but when there is the need to initialize an instance of a class in several different ways, the "simple" solution turns out to be more complicated: it demands the programmer choosing different types to do syntactic overloading, or adding "flags" to the constructor, or using arguments with default values and have a complex logic with if's inside the constructor trying to guess what kind of construction is needed (the last two options get worse when trying to inherit constructors). Eiffel offers the possibility of having more than one creation routine, which is a bit more complex than other "simple" languages, but actually removes complexity from the software construction process.

I have been critical of the approach taken in .NET that you don't need to learn JavaScript. It seems the Ajaxian agrees:

The platform is in the style of "you will not need to learn JavaScript". Instead, Java developers stay in Java land, put their hands over their ears and shout LA LA LA LA.

Google has launched Google Code Search, a source code search engine. And what a search engine it is, even though it's still in beta!

Searching for symbols is no problem, and there's full regular expression search. Wow, that must be computationally expensive.


You can search by license - although the Eiffel Forum License is not recognised - perhaps that's another reason why the Eiffel community should standardise on something like the MIT license.

You can restrict your search by language - just add lang:eiffel to your search.

Putting it all together, we could search for Gobo classes that contain old-style creation instructions: Gobo "!!" lang:eiffel. Naturally this search will also include other uses of "!!" within Eiffel code, yet the data we want is there too.

I don't think it will be long before Google Code Search becomes almost indispensible. All we need now is some accepted protocol for the use of indexing clause tags and we will finally be able to realise the potential of indexing clauses!