Difference between revisions of "Replication"

(→‎Three cases of conforming repeated inheritance)
Line 1: Line 1:
 +
One definition of replication is: the action or process of reproducing or duplicating.
  
−
Work in progress!
+
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.
  
−
We start with some very basic examples, for this we consider all the classes not to be inherited by ANY.
+
Although not explicitely 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 eralier) handles replication (won't help us here since it doesn't comply to the standard).
  
−
== Example set ==
+
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.
−
==== Basic cases of direct repeated inheritance ====
+
  
−
The following set of example will base on class B:
+
In the following a set of rules are given that are meant to replace rules 8.16.2 through 8.16.5.
  
 +
== New and modified rules: ==
 +
 +
====8.1.2 Semantics: Repeated Inheritance rule====
 +
Let D be a class and B1, ... Bn (n >= 2) be parents of D based on classes having a common ancestor
 +
A. Let a1,...an be attributes of these respective parents, all having as one of their seeds the same
 +
attribute a of A. Then:
 +
1 Any subset of these attributes inherited by D under the same final name in D yields a
 +
single attribute of D.
 +
2 Any two of these attributes inherited under a different name yield two attributes of D.
 +
 +
====8.16.3 Definition: '''Not isolated''' feature====
 +
 +
A feature ''f'' of '''D''' is '''isolated''' iif for each proper ancestor feature ''af'' defined in an ancestor ''A'' one of the following properties hold:
 +
 +
* Feature ''af'' is deferred.
 +
* Feature ''af'' is an attribute without Attribute part.
 +
* There is only one conformance path from ''A'' to ''D''.
 +
* All the ancestors of ''af'' in ''D'' have the same name.
 +
* ''af'' is redefined in a class ''C'', such that ''C'' is both an ancestor of ''D'' and a proper decendant of ''A''.
 +
 +
Feature ''f'' is '''not isolated''' in respect to ancestor feature ''af'' if none of the above properties hold.
 +
 +
Informal:
 +
 +
* An intermediate feature is '''isolated'''.
 +
* Example:
 +
{|border="0" cellpadding="2" cellspacing="0" align="center"
 +
|-valign="top" -halign="center"
 +
|<code>[eiffel, N]
 +
class
 +
  B
 +
feature
 +
  f do ... end
 +
end
 +
</code>
 +
|
 
<code>[eiffel, N]
 
<code>[eiffel, N]
 
class
 
class
 +
  C
 +
inherit
 
   B
 
   B
 +
      rename f as f1 redefine f1 end
 
feature
 
feature
−
   f: INTEGER
+
   f1 do ... end
−
  g
+
−
      do  
+
−
        f := f + 1
+
−
      end
+
 
end
 
end
 
</code>
 
</code>
−
====Three cases of non-conforming repeated inheritance====
+
|
−
Lets have look at D1 that repeatedly inherits from B:
+
 
<code>[eiffel, N]
 
<code>[eiffel, N]
 
class
 
class
−
   D1
+
   D
−
inherit {NONE}
+
inherit
 +
  C
 +
      select f1 end
 +
  B
 +
      rename f as f2 redefine f2 end
 
   B
 
   B
−
       rename f as f1, g as g1 end
+
       rename f as f3 end
 +
feature
 +
  f2 do ... end
 +
end
 +
</code>
 +
|}
 +
Feature ''f1'' of class ''D'' is ''isolated'' since it is redefined in class ''C''. Feature ''f2'' is also '''isolated''', it is redefined in class ''D''. Feature ''f3'' is '''not isolated'''.
 +
 
 +
====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 iif the body of ''af'' satisfies the following:
 +
 
 +
Every feature ''m'' that is called in ''af'' on a target of type like Current must be inherited through clauses ''P1''...''Pn'' with the same name.
 +
 
 +
Informal:
 +
 
 +
* Example:
 +
{|border="0" cellpadding="2" cellspacing="0" align="center"
 +
|-valign="top" -halign="center"
 +
|<code>[eiffel, N]
 +
class
 
   B
 
   B
−
      rename f as f2, g as g2 end
 
 
feature
 
feature
−
end    
+
  f do g end
 +
  g do ... end
 +
 
 +
end
 +
</code>
 +
|
 +
<code>[eiffel, N]
 +
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
 
</code>
 
</code>
 +
|}
 +
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 throught 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.
  
−
And an informal description of the semantics: An object of class D1 contains two physical attributes (f1 and f2). A call to feature g1 results in f1 being incremented and a call to g2 increments f2.
+
====8.16.X Semantics: Unfolded form of a '''not isolated''' feature====
  
−
Lets do the same for D2:
+
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 of''P1'',...,''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:
 +
{|border="0" cellpadding="2" cellspacing="0" align="center"
 +
|-valign="top" -halign="center"
 +
|<code>[eiffel, N]
 +
class
 +
  B
 +
feature
 +
  f do g end
 +
  g do end
 +
end
 +
</code>
 +
|
 
<code>[eiffel, N]
 
<code>[eiffel, N]
 
class
 
class
−
   D2
+
   D
−
inherit {NONE}
+
inherit
 
   B
 
   B
−
       rename g as g1 end
+
       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
 +
</code>
 +
|}
 +
 
 +
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:
 +
 
 +
{|border="0" cellpadding="2" cellspacing="0" align="center"
 +
|-valign="top" -halign="center"|
 +
<code>[eiffel, N]
 +
class
 +
  D
 +
inherit
 
   B
 
   B
−
       rename g as g2 end
+
       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
 
feature
−
end    
+
  f1 do ... end
 +
  g1 do end
 +
  f2 do g2 end
 +
  g2 do end
 +
end
 
</code>
 
</code>
 +
|}
  
−
An object of class D2 contains one physical attribute (f). A call to either g1 or g2 results in f being incremented.
+
====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)
  
−
Class D3 should be rejected by the compiler:
+
It is valid for a feature f inherited by a class D from an ancestor A to involve a feature g of A other than as the feature of a qualified call if and only if there is exactly one potential version of g in D.
 +
 
 +
Informative: This rule implies one very simple property of unqualified calls, they are not influenced by selects.
 +
 
 +
Example of an invalid System according to this rule:
 +
 
 +
{|border="0" cellpadding="2" cellspacing="0" align="center"
 +
|-valign="top" -halign="center"
 +
|<code>[eiffel, N]
 +
class
 +
  B
 +
feature
 +
  f
 +
      do g end
 +
  g  do ... end
 +
end
 +
</code>
 +
|
 
<code>[eiffel, N]
 
<code>[eiffel, N]
 
class
 
class
−
   D3
+
   D
−
inherit {NONE}
+
inherit
 
   B
 
   B
−
       rename f as f1 end
+
       rename g as g1 redefine g1 select g1 end
 
   B
 
   B
−
       rename f as f2 end
+
       rename g as g2 redefine g2 end
 
feature
 
feature
−
end    
+
  g1 do ... end
 +
  g2 do ... end
 +
end
 
</code>
 
</code>
 +
|-
 +
|}
  
−
Since an object of class D3 would have two physical attributes f1 and f2, it is not clear which one g should increment.
+
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.
  
−
====Three cases of conforming repeated inheritance====
+
====8.16.5 Semantics: Replication Semantics rule====
−
Lets look now at different variants of class D1. They looks exactly as class D1 except that they inherit conforming from B (twice) and therefore need to solve the conflicts between f1-f2 and g1-g2 by selecting. Let <math>DC1_fx_gx</math> be the variant of D1 that selects fx and gx.
+
−
There are four such variants: DC1_f1_g1, DC1_f1_g2, DC1_f2_g1, DC1_f2_g2.
+
  
−
Even though the following examples contain conforming inheritance, we will start by investigating their semantics in the case where static and dynamic type are equal. When the variants DC1
+
This rule is not necessary and should be put into informative text.
−
<math> sqrt (2^2) </math>
+

Revision as of 16:17, 22 September 2006

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 explicitely 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 eralier) 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.

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

New and modified rules:

8.1.2 Semantics: Repeated Inheritance rule

Let D be a class and B1, ... Bn (n >= 2) be parents of D based on classes having a common ancestor A. Let a1,...an be attributes of these respective parents, all having as one of their seeds the same attribute a of A. Then: 1 Any subset of these attributes inherited by D under the same final name in D yields a single attribute of D. 2 Any two of these attributes inherited under a different name yield two attributes of D.

8.16.3 Definition: Not isolated feature

A feature f of D is isolated iif for each proper ancestor feature af defined in an ancestor A one of the following properties hold:

  • Feature af is deferred.
  • Feature af is an attribute without Attribute part.
  • There is only one conformance path from A to D.
  • All the ancestors of af in D have the same name.
  • af is redefined in a class C, such that C is both an ancestor of D and a proper decendant of A.

Feature f is not isolated in respect to ancestor feature af if none of the above properties hold.

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 is isolated since it is redefined in class C. Feature f2 is also isolated, it is redefined in class D. Feature f3 is not isolated.

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 iif the body of af satisfies the following:

Every feature m that is called 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 throught 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 a feature f inherited by a class D from an ancestor A to involve a feature g of A other than as the feature of a qualified call if and only if there is exactly one potential version of g in D.

Informative: This rule implies one very simple property of unqualified calls, 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=4621"