blog Forthcoming language improvements

manus_eiffel's picture

The past 6 months we have been working on some new language improvements to simplify and improve the expressiveness of Eiffel.

The first improvement is the conditional expression. Very often, depending on some boolean value you expect either one result or another. Although one can express this, it is sometime tedious and/or not very readable.

blog Eiffel for Visual FoxPro Programmers: Events, Agents and State Machines

No matter what language used, software is concerned with the states of objects and transitions between them. Within the Visual FoxPro paradigm, I saw the notion of a State Machine as a fantastic solution to a common problem: How do I make my interfaces respond appropriately to user interaction?

blog Stumbling across errors in language design

The recently floated proposal to add the `across' looping construct to Eiffel seems seriously mistaken.


Creating a .NET delegate object from an Eiffel routine

Someone recently asked me how to create a .NET delegate from an Eiffel routine. Ideally it would be nice to simply do:

my_delegate := (agent my_routine).to_delegate

where `to_delegate' is a query from the ROUTINE class. However this feature does not yet exist.

blog Wrapper generation for agent calls

colin-adams's picture

I have recently become irritated by having to code dummy arguments for routines to be used as agents. Eric Bezault suggests that Eiffel could be usefully extended to eliminate the need for this.

So I have sketched a proposal here

blog Win, win, win.

colin-adams's picture

Many people have said that they dislike having to export a routine just so that it can be used as an agent in a pre-condition. The objection is that if the routine does not naturally belong to the ADT, then it should not be exported to ANY. Well, this is a valid point, although there are already routines in ANY that do not belong in the ADT of most classes. Such as generating_type.

blog Correctness conditions (2) for calling an agent

colin-adams's picture

Following on from correctness_conditions_for_calling_an_agent, I have thought about the following scheme (it would require ECMA to be amended to require a tag on assertions, but this should be done anyway.

blog Correctness conditions for calling an agent

colin-adams's picture

I was recently reading the paper "From Design Patterns to Reusable Components: The Factory Library by Karine Arnout and Bertrand Meyer" and I noticed that although they had succeeded in turning the pattern "Abstract Factory" into a component, the resulting class (ABSTRACT_FACTORY) did not have a sound contract.

Syndicate content