Difference between revisions of "Transposition"
m |
m (→Transposition) |
||
| Line 4: | Line 4: | ||
==Transposition== | ==Transposition== | ||
| − | We talk of 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. | + | We talk of 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: |
| + | |||
| + | {|border="0" cellpadding="2" cellspacing="0" align="center" | ||
| + | |-valign="top" -halign="center" | ||
| + | |<code>[eiffel, N] | ||
| + | class | ||
| + | B | ||
| + | feature | ||
| + | f do g end | ||
| + | g do end | ||
| + | end | ||
| + | </code> | ||
| + | | | ||
| + | <code>[eiffel, N] | ||
| + | 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 | ||
| + | </code> | ||
| + | |} | ||
| + | |||
| + | Has the transposed form: | ||
| + | |||
| + | {|border="0" cellpadding="2" cellspacing="0" align="center" | ||
| + | |-valign="top" -halign="center"| | ||
| + | <code>[eiffel, N] | ||
| + | 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 | ||
| + | </code> | ||
| + | |} | ||
| + | |||
| + | We clearly have | ||
| + | |||
| + | |||
Transposition was never necessary in Eiffel compilers but it is now | Transposition was never necessary in Eiffel compilers but it is now | ||
Revision as of 07:43, 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 talk of 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 |
Has the transposed form:
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:
