Replication

Revision as of 17:02, 26 September 2006 by Konradm (Talk | contribs) (→‎Talking about features)

Author: Matthias Konrad

Known problems of the following text: Calls to targets of type like Current do not include usage of an attribute when it is assigned to.


One definition of replication is: the action or process of reproducing or duplicating.

Both ETL, OOSC2 and the standard use the term replication as if its semantics were common knowledge. I disagree to that, since I was not able to get consistent information about replication from notable experts. Hence it is certainly a term to be defined much more carefully.

Although not explicitly stated, it seems that a replicated feature has an unfolded form. That would mean, that we could get rid of replication by reducing it to other language mechanisms (As it is done for precursors). This is how the current ISE compiler (5.7 and earlier) handles replication (won't help us here since it doesn't comply to the standard).

If an unfolded form cannot be found, this has a huge impact on the standards text. The semantics of unqualified calls in the context of replicated features would for example not be defined.

Talking about features

The standard is not allways clear in the way it talks about a feature. (Personally I feel it is inconsistent but I am shure that it is at least obscure).

There is a one to one connection between feature and Feature_body. Every feature has exacly one Feature_body. Every Feature_body belongs to exactly one feature. Meaning that, two different Feature_body's belong to two different features and two different features have two different Feature_body's.

Have a look at this example: 


class
   B
feature
   f do ... end
end
 
class
   D
inherit
   B
      rename f as f1 select f1 end
   B
      rename f as f2 redefine f2 end
feature
   f2 do ... end
end

The above system has two features. The feature named f1 in class D and the feature named f in class B are one and the same feature. Its body is defined in class B. It is valid to say: Feature f1 of class D and feature f of class B are the same features. The second feature in the system is feature f2 of class D or the feature named f2 in class D. This feature has its body defined in class D.


By saying feature, we indirectly reference a certain Feature_body. Indirectly, because we can say: "feature f of a class D", when the Feature_body of f belongs to an Ancestor class A of D (Given that f is not redeclared on the inheritance path between A and D).

The name of feature f is always the name stated in its Feature_body. A feature may have different names in different classes (through renaming). It is thus legal to say: "Feature f with name fn in class D, when feature f is renamed to fn somewhere along the according inheritance path.

In the following a set of rules are given that are meant to replace rules 8.16.2 through 8.16.5.

8.16.2 Semantics: Repeated Inheritance rule

This rule will be obsolete but some thing similar might be introduced as informal text.

8.16.3 Definition: Not isolated feature

A feature f of class D is isolated in D if the following two statements are true:

  • Feature f has only one name in D
  • There is no feature f2 in class D such that f2 is a version of f.

Otherwise f is not isolated in class D.

Informal:

  • An intermediate feature is isolated.
  • Example:
class
   B
feature
   f do ... end
end
 
class
   C
inherit
   B
      rename f as f1 redefine f1 end
feature
   f1 do ... end
end
 
class
   D
inherit
   C
      select f1 end
   B 
      rename f as f2 redefine f2 end
   B
      rename f as f3 end
feature
   f2 do ... end
end
  • Feature f1 of class D (whose body is in class C) is isolated in class D.
  • Feature f2 of class D (whose body is in class D) is isolated in class D.
  • Feature f3 of class D (whose body is in class B) is no isolated in class D, since feature f2 of class B is a version of it.

8.16.X Validity: not isolated feature

Let feature f with name fn of class D be a not isolated feature in respect to ancestor feature af of class B. Let P1...Pn be the parent clauses through which D inherits feature af with name fn.

The not isolated feature f is valid if and only if the body of af satisfies the following:

Every feature m that is used in af on a target of type like Current must be inherited through clauses P1...Pn with the same name.

Informal:

  • Example:
class
   B
feature
   f do g end
   g do ... end
 
end
 
class
   D
inherit
   B
      rename f as f1, rename g as g1, select f1, g1 end
   B
      rename f as f2, g as g2 end 
   B
      rename f as f2, g as g3 end
feature
   f1 do ... end
end

There are several not isolated features in D: f1, g1, f2, g2, g3. Only f2 is not a valid not isolated feature. It is inherited through the second and third parent part. Feature f has a call to g (with target of type like Current) and g is inherited with a different name through the second and third parent part. Hence f2 is not valid.

8.16.X Semantics: Unfolded form of a not isolated feature

Again, let feature f with name fn of class D be a not isolated feature in respect to ancestor feature af of class B. Let P1...Pn be the parent clauses through which D inherits feature af with name fn. Let CP be the conformance paths from B to D that enter D through the parent parts P1.

The unfolded form of feature f consists of a new redefine fn clause in each ofP1,...,Pn and the corresponding new feature that is further called the replicate of f.

The replicate of f has the same signature and name as the inherited routine f. The implementation of the replicate is also similar with the exception of calls with targets of type like current. The features of these calls are renamed according to the renamings that occur on the conformance path CP.

Informative:

  • The validity rule of not isolated features warrant, that all the conformance paths from B to D yield the the same renamings.
  • Example:
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

The not isolated features of class D are g1, f1 and g2. The following snippet shows class D with all its not isolated features unfolded: 

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

8.16.4 Validity: Call Sharing rule

(The rule described here would replace 8.16.4. Maybe an other name is needed for the rule)

It is valid for an isolated feature f inherited by a class D from an ancestor A to use feature g of A on a target of type like Current if and only if there is exactly one potential version of g in D.

Informative:

  • This rule implies one very simple property of calls to targets of type like Current, they are not influenced by selects.
  • Example of an invalid System according to this rule:
class
   B
feature
   f
      do g end
   g  do ... end
end
 
class
   D
inherit
   B
      rename g as g1 redefine g1 select g1 end
   B
      rename g as g2 redefine g2 end
feature
   g1 do ... end
   g2 do ... end
end

Feature f is inherited by class D from ancestor A. The feature involves an unqualified call to feature g. Since feature g has two potential versions in D (g1 and g2) the system is invalid.

8.16.5 Semantics: Replication Semantics rule

This rule is not necessary and should be put into informative text.

Retrieved from "https://dev.eiffel.com/index.php?title=Replication&oldid=4706"