Flat Short Form

In Eiffel terminology, the ShortForm of class source code is a view that includes only its interface; implementation is excluded. It gives the names and signatures of methods and instance variables. It includes pre- and post-conditions and class invariants. It will include direct inheritance relationships. In effect, the ShortForm turns every class into a pure abstract class.

A FlatForm? of class source code is a view that lists features declared directly by the class together with those it inherits. Thus, everything, no matter where it came from. The inheritance hierarchy is "flattened out".

A FlatShortForm is a combination of the Flat and Short filters. It contains all the interface, everything you need to use the class, no matter where it came from.

These are all forms of documentation for the class generated automatically from the source by tools. You can also see the FlatShortForm as a specification for the class. An early architecture for a project might consist of Short and/or Flat forms of the important base classes. These would be compilable, type-checkable, but wouldn't contain actual code. The implementations would be filled in later.

Contributors: DaveHarris

See also: DesignByContract.

I mention this in the context of DesignByContract, to show some of the role of assertions.

One of the differences between assertions and UnitTests is that assertions are right there in the code. Sometimes this is an advantage, sometimes a disadvantage. The disadvantage is mitigated by inheritance (so they are in parent class code, not your own); the FlatForm? undoes the effect of inheritance for you. The ShortForm mitigates another part of it, by showing you just the assertions (rather like looking at just the unit tests, in their own file).

A rich Eiffel environment should be able to hide and show assertions, and hide and show implementation, at will, while working on the code. This would further reduce the difference between assertions and UnitTests.

-- DaveHarris