Minor-ECMA-problems: Difference between revisions
No edit summary |
|||
| Line 2: | Line 2: | ||
====Motivation==== | ====Motivation==== | ||
There are several situations in which the ECMA standard uses unfoled forms as a vehicle to describe | 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: | ||
{|border="0" cellpadding="2" cellspacing="0" align="center" | {|border="0" cellpadding="2" cellspacing="0" align="center" | ||
| Line 20: | Line 20: | ||
<code>[eiffel, N] | <code>[eiffel, N] | ||
class | class | ||
D | |||
inherit | inherit | ||
B | B | ||
| Line 28: | Line 28: | ||
end | end | ||
</code> | </code> | ||
|} | |||
It feels natural to unfold class B first and then inherit C from its unfolded form before C is unfolded: | |||
{|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, g as g1, select f1, g1 end | |||
B | |||
rename f as f2, g as g2 end | |||
end | |||
</code> | |||
|} | |} | ||
This system is not valid anymore. The call-equivalent of the inline-agent (here named fict_name) has a call to g which has several | |||
potential versions in D. 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. | |||
Revision as of 16:27, 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 |
This system is not valid anymore. The call-equivalent of the inline-agent (here named fict_name) has a call to g which has several potential versions in D. 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.
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)