Difference between revisions of "Minor-ECMA-problems"
(→Motivation) |
(→Motivation) |
||
Line 65: | Line 65: | ||
potential versions in D. Hence this is not a valid system. | potential versions in D. Hence this is not a valid system. | ||
The same problem can occur with calls to Precursor. The programmer cannot do anything about it since he has no knowledge of the fictous name of the call-equivalent. | The same problem can occur with calls to Precursor. The programmer cannot do anything about it since he has no knowledge of the fictous name of the call-equivalent. | ||
+ | There should have been some coupling between the name f and the name of the call-equivalent of the inline-agent. The unfolded form of a renaming would then also rename all the coupled name (a precice definition follows). Our final example woul become: | ||
+ | {|border="0" cellpadding="2" cellspacing="0" align="center" | ||
+ | |-valign="top" -halign="center" | ||
+ | |<code>[eiffel, N] | ||
+ | class | ||
+ | B | ||
+ | feature | ||
+ | f | ||
+ | do | ||
+ | (agent fict_name).call ([]) | ||
+ | end | ||
+ | g: INTEGER | ||
+ | fict_name | ||
+ | do | ||
+ | g := g + 1; print (g) | ||
+ | end | ||
+ | end | ||
+ | </code> | ||
+ | | | ||
+ | <code>[eiffel, N] | ||
+ | class | ||
+ | D | ||
+ | inherit | ||
+ | B | ||
+ | rename f as f1, fict_name1, g as g1 | ||
+ | redefine f1, fict_name1 | ||
+ | select f1, g1, fict_name1 end | ||
+ | B | ||
+ | rename f as f2, fict_name as fict_name2, g as g2 | ||
+ | redefine f2, fict_name2 end | ||
+ | feature | ||
+ | f1 do (agent fict_name1).call ([]) end | ||
+ | fict_name1 do g1 := g1 + 1; print (g1) end | ||
+ | |||
+ | f2 do (agent fict_name2).call ([]) end | ||
+ | fict_name2 do g2 := g2 + 1; print (g2) end | ||
+ | end | ||
+ | </code> | ||
+ | |} | ||
A feature name can be coupled to the name of an other feature. | A feature name can be coupled to the name of an other feature. |
Revision as of 07:36, 25 September 2006
Definition: Coupled name
Motivation
There are several situations in which the ECMA standard uses unfoled forms as a vehicle to describe semantics. When this unfoled forms need names, like in Precursor, inline agents and not isolated features. These names have an influence on the semantics of the system. An example:
class B feature f do (agent do g := g + 1; print (g) end).call ([]) end g: INTEGER end |
class D inherit B rename f as f1, g as g1, select f1, g1 end B rename f as f2, g as g2 end end |
It feels natural to unfold class B first and then inherit C from its unfolded form before C is unfolded:
class B feature f do (agent fict_name).call ([]) end g: INTEGER fict_name do g := g + 1; print (g) end end |
class D inherit B rename f as f1, g as g1, select f1, g1 end B rename f as f2, g as g2 end end |
The call-equivalent of the inline-agent (here named fict_name) has a call to g which has several potential versions in D. Hence this is not a valid system. The same problem can occur with calls to Precursor. The programmer cannot do anything about it since he has no knowledge of the fictous name of the call-equivalent. There should have been some coupling between the name f and the name of the call-equivalent of the inline-agent. The unfolded form of a renaming would then also rename all the coupled name (a precice definition follows). Our final example woul become:
class B feature f do (agent fict_name).call ([]) end g: INTEGER fict_name do g := g + 1; print (g) end end |
class D inherit B rename f as f1, fict_name1, g as g1 redefine f1, fict_name1 select f1, g1, fict_name1 end B rename f as f2, fict_name as fict_name2, g as g2 redefine f2, fict_name2 end feature f1 do (agent fict_name1).call ([]) end fict_name1 do g1 := g1 + 1; print (g1) end f2 do (agent fict_name2).call ([]) end fict_name2 do g2 := g2 + 1; print (g2) end end |
A feature name can be coupled to the name of an other feature.
New Behaviour of renaming
The unfolded form of a renaming is the renaming itself plus the unfolded forms of the renamings of all the coupled names.
Precursor
The current definition of the Precursor semantics in the ECMA standard (8.10.11)