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)