Difference between revisions of "Transposition"

Revision as of 09:07, 24 October 2006

With the ECMA Eiffel Standard, the dynamic binding semantics of the Eiffel language are slightly changed. This puts some additional burdens on the compiler implementor. We will discuss two of them:

• The need for copying inherited features in descendants.
• More complex dynamic binding.

Transposition

We speak of the transposition of a feature, when we copy an inherited feature to a descendant class and adapt its content according to the inheritance path. When all the inherited features of a class are transposed, we get the flat short form of the class. Transposition is very interesting, since it seems to be the solution to some ambiguities in the language, namely repeated inheritance and replication. In the following system:

class
   B
feature
   f do g end
   g do end
end

class
   D
inherit
   B
      rename f as f1, g as g1 redefine f1 select f1, g1 end
      rename f as f2, g as g2 end
feature
   f1 do ... end
end

class D has the transposed form (we ommit the features from ANY):

class
   D
inherit
   B
      rename f as f1, g as g1 redefine f1, g1 select f1, g1 end
      rename f as f2, g as g2 redefine f2, g2 end
feature
   f1 do ... end
   g1 do end   
   f2 do g2 end
   g2 do end   
end

So the transposed form of class D redefines all the features of its parent. Some rather complex rules of the standard become obsolete, when it is just stated, that every inherited feature needs to be transposed (8.16.2, 8.16.3, 8.16.4, 8.16.5). During the transposition there might be conflicts. It is possible that two transposed features have the same name. It remains to be specified how such cases are handled. One solution is to say, that they are valid iif their (transposed) body is equivalent.

We clearly have

Transposition was never necessary in Eiffel compilers but it is now

For the following discussion we use this system of five classes: