Team Eiffel

Greg C has posted an interesting article to the ISE Eiffel mailing list, suggesting that Eiffel should embrace metaprogramming rather than Aspect Oriented Programming, which Greg sees as a limited form of metaprogramming best suited to people who "don't get" metaprogramming. Greg writes:

I think it would be nice if we had better facilities for metaprogramming with Eiffel, and simply did not worry about AOP. There are interesting things we could accomplish by thinking of Eiffel source code as data, amenable to manipulation by other programs. And the relatively simple syntax of Eiffel lends itself to this.

For example, we might want to add contracts to all features that receive a string, to guarantee the string is not void. Or this could be generalized to all reference types in an argument list.

Or we could specify that all the classes in a given cluster only have dependencies on a known set of clusters. This would help support library maintenance and reduce code bloat when a new class unintentionally pulls in a new cluster.

John_Duh replied, voicing concerns that he didn't want "some sort of preprocessor", and suggesting a more dynamic runtime approach.

I'd rather see the provision for compiler plugins. These would be written in Eiffel and would validate or transform the Eiffel code after the compiler parses it but before validity checking and code generation. It would then be straightforward to implement the ideas that Greg offered. The catch is that Eiffel, with its "compile-the-world" approach, doesn't readily lend itself to a plugin architecture (although ISE's Dynamic Linking in Eiffel makes some headway in this direction).

Other tentative steps towards metaprogramming are the APIs offered by Visual Eiffel and Eiffel/S that enable the compilation database to be examined by Eiffel code.