Difference between revisions of "Transposition"
m (→Transposition) |
m |
||
Line 30: | Line 30: | ||
|} | |} | ||
− | class D has the transposed form (we | + | class D has the transposed form (we omit the features from ANY): |
{|border="0" cellpadding="2" cellspacing="0" align="center" | {|border="0" cellpadding="2" cellspacing="0" align="center" | ||
Line 52: | Line 52: | ||
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. | 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. | ||
+ | Apart from its simplicity to describe the semantics of the language, transposition is very (mabe too) expensive. It is obvious, even from the previous example, that not every inherited feature needs to be transposed. | ||
Revision as of 08:21, 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 omit the features from ANY):
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.
Apart from its simplicity to describe the semantics of the language, transposition is very (mabe too) expensive. It is obvious, even from the previous example, that not every inherited feature needs to be transposed.
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: