Difference between revisions of "Minor-ECMA-problems"

(Motivation)
Line 2: Line 2:
  
 
====Motivation====
 
====Motivation====
There are several situations in which the ECMA standard uses unfoled forms as a vehicle to describe the semantics in a simple way. 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. Two examples are presented:
+
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
   C
+
   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 08: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)