Difference between revisions of "Conversion rules"

Line 38: Line 38:
  
 
The answer is '''no''' and thus the code regarded as valid.
 
The answer is '''no''' and thus the code regarded as valid.
 +
 +
Summary:
 +
* correct result: <font color="green">invalid</font>
 +
* old rules: <font color="red">valid</font>
 +
* wildcard rule: <font color="green">invalid</font>
 +
* complex rule: <font color="green">invalid</font>
  
  
Line 61: Line 67:
  
 
The answer is '''no''' and thus the code regarded as valid.
 
The answer is '''no''' and thus the code regarded as valid.
 +
Summary:
 +
* correct result: <font color="green">invalid</font>
 +
* old rules: <font color="red">valid</font>
 +
* wildcard rule: <font color="green">invalid</font>
 +
* complex rule: <font color="green">invalid</font>
  
 
====Example 3====
 
====Example 3====
Line 82: Line 93:
 
The answer is '''no''' and thus the code regarded as valid.
 
The answer is '''no''' and thus the code regarded as valid.
 
Summary:
 
Summary:
* correct result: invalid
+
* correct result: <font color="green">invalid</font>
* old rules: valid
+
* old rules: <font color="red">valid</font>
* wildcard rule: invalid
+
* wildcard rule: <font color="green">invalid</font>
* complex rule: invalid
+
* complex rule: <font color="green">invalid</font>
 
+
 
====Example 4====
 
====Example 4====
 
This is an example which is valid under the current rules and should remain valid. Even though we inherit from A[ANY] the conversion to A[STRING] should be valid.
 
This is an example which is valid under the current rules and should remain valid. Even though we inherit from A[ANY] the conversion to A[STRING] should be valid.
Line 114: Line 124:
  
 
Summary:
 
Summary:
* correct result: valid
+
* correct result: <font color="green">valid</font>
* old rules: valid
+
* old rules: <font color="green">valid</font>
* wildcard rule: valid
+
* wildcard rule: <font color="green">valid</font>
* complex rule: valid
+
* complex rule: <font color="green">valid</font>
  
 
====Example 5====
 
====Example 5====
Line 145: Line 155:
  
 
Summary:
 
Summary:
* correct result: valid
+
* correct result: <font color="green">valid</font>
* old rules: valid
+
* old rules: <font color="green">valid</font>
* wildcard rule: valid
+
* wildcard rule: <font color="green">valid</font>
* complex rule: valid
+
* complex rule: <font color="green">valid</font>
  
 +
====Example 6====
 +
This is the second example which is valid under the current rules. The code is valid as the ''Conversion principle'' cannot possibly be violated.
 +
 +
* eweasel test: convert-to-base-class-inherited
 +
 +
<eiffel>
 +
class A[G]
 +
end
 +
 +
class B[G->INTEGER_REF]
 +
inherit
 +
      A[G]
 +
convert
 +
  to_a: {A[DOUBLE]}
 +
feature
 +
  to_a: A[DOUBLE]
 +
      do end
 +
end
 +
</eiffel>
 +
'''VYCQ(3)''':
 +
 +
Is B[INTEGER_REF] conform to A[DOUBLE]?
 +
 +
The answer is '''no''' and thus the code regarded as valid.
 +
 +
Summary:
 +
* correct result: <font color="green">valid</font>
 +
* old rules: <font color="green">valid</font>
 +
* wildcard rule: <font color="red">invalid</font>
 +
* complex rule: <font color="green">valid</font>
  
 
==Understanding the matter==
 
==Understanding the matter==
Line 178: Line 218:
 
'''Example 1 for VYCQ'(2):'''
 
'''Example 1 for VYCQ'(2):'''
  
  Is A[NONE] conform to A[G]?
+
  Is A[WILDCARD] conform to A[G]?
  
 
The answer is '''yes''' and the validity rule is violated, which is good.
 
The answer is '''yes''' and the validity rule is violated, which is good.
Line 185: Line 225:
 
'''Example 2 for VYCQ'(2):'''
 
'''Example 2 for VYCQ'(2):'''
  
  Is A[NONE] conform to A[STRING]?
+
  Is A[WILDCARD] conform to A[STRING]?
  
 
The answer is '''yes''' and we reject the code.
 
The answer is '''yes''' and we reject the code.
Line 192: Line 232:
 
'''Example 3 for VYCQ'(2):'''
 
'''Example 3 for VYCQ'(2):'''
  
  Is A[NONE,NONE] conform to A[G,G]?
+
  Is A[WILDCARD,WILDCARD] conform to A[G,G]?
  
 
The answer is again '''yes''' and therefore the code not valid.
 
The answer is again '''yes''' and therefore the code not valid.
Line 199: Line 239:
 
'''Example 4 for VYCQ'(2):'''
 
'''Example 4 for VYCQ'(2):'''
  
   Is B[NONE] conform to A[STRING]?
+
   Is B[WILDCARD] conform to A[STRING]?
  
 
As ''B'' only inherits from ''A[ANY]'' the answer is '''no''' and we're fine.
 
As ''B'' only inherits from ''A[ANY]'' the answer is '''no''' and we're fine.
Line 206: Line 246:
 
'''Example 5 for VYCQ'(2):'''
 
'''Example 5 for VYCQ'(2):'''
  
  Is B[NONE,NONE] conform to A[DOUBLE,INTEGER]?
+
  Is B[INTEGER,DOUBLE] conform to A[DOUBLE,INTEGER]?
 +
 
 +
The answer is '''no''' and therefore the code valid.
 +
 
 +
'''Example 6 for VYCQ'(2):'''
 +
 
 +
Is B[WILDCARD] conform to A[DOUBLE]?
  
The answer is '''no''' and therefore the code valid. The answer is only no because nothing conforms to an expanded type but the expanded type itself.
+
The answer is '''ues''' and therefore the code valid. But it should be invalid because the constraint INTEGER_REF and the fact that DOUBLE is frozen makes it impossible to create a type which satisfies both, the conformance to INTEGER_REF and to DOUBLE.

Revision as of 09:44, 22 January 2007

Warning.png Warning: Warning: Article under development

Introduction

This article discusses issues recently discovered for the following two validity rules:

  • 8.15.7 Validity: Conversion Procedure rule, Validity code: VYCP
  • 8.15.8 Validity: Conversion Query rule, Validity code: VYCQ

There are cases where both of them violate the conversion principle:

  • 8.15.3 Validity: Conversion principle: No type may both conform and convert to another.

Examples

As the conversion rules are strongly dual, each example can be transformed to show the issue for its sibling.

Example 1

We have a conversion to the current type of the class. It should not be allowed. Currently no rule rejects this code.

  • eweasel test: convert-to-current-type
class A[G]
convert
   to_a: {A[G]}
feature
   to_a: A[G]
       do end
end

The conversion to A[G] should indeed not be valid because they are conform.

The only rule that matters in our case is VYCQ(3).

What VYCQ(3) asks is the following

Is A[ANY] conform to A[G]?

The answer is no and thus the code regarded as valid.

Summary:

  • correct result: invalid
  • old rules: valid
  • wildcard rule: invalid
  • complex rule: invalid


Example 2

This example shows a special case which is valid under the current rule but can possibly lead to a conflict between conformance and conversion.

  • eweasel test: convert-to-possible-actual-type
class A[G]
convert
   to_a: {A[STRING]}
feature
   to_a: A[STRING]
       do end
end

In the case where G's actual type parameter is a subtype of STRING it yields in a situation where the two types are conform again.

The interesting rule is again VYCQ(3):

Is A[ANY] conform to A[STRING]?

The answer is no and thus the code regarded as valid. Summary:

  • correct result: invalid
  • old rules: valid
  • wildcard rule: invalid
  • complex rule: invalid

Example 3

  • eweasel test: convert-to-base-class
class A[G,H]
convert
   to_a: {A[G,G]}
feature
   to_a: A[G,G]
      do end
end

VYCQ(3):

Is A[ANY,ANY] conform to A[G,G]?

The answer is no and thus the code regarded as valid. Summary:

  • correct result: invalid
  • old rules: valid
  • wildcard rule: invalid
  • complex rule: invalid

Example 4

This is an example which is valid under the current rules and should remain valid. Even though we inherit from A[ANY] the conversion to A[STRING] should be valid.

  • eweasel test: convert-to-base-class-inherited
class A[G]
end
 
class B[G]
inherit
      A[ANY]
convert
   to_b: {A[STRING]}
feature
   to_b: A[STRING]
       do end
end

VYCQ(3):

Is B[ANY] conform to A[STRING]?

The answer is no and thus the code regarded as valid.

Summary:

  • correct result: valid
  • old rules: valid
  • wildcard rule: valid
  • complex rule: valid

Example 5

This is the second example which is valid under the current rules. The code is valid as the Conversion principle cannot possibly be violated.

  • eweasel test: convert-to-base-class-inherited
class A[G,H]
end
 
class B[G->INTEGER,H->DOUBLE]
inherit
      A[G,H]
convert
   to_a: {A[DOUBLE,INTEGER]}
feature
   to_a: A[DOUBLE,INTEGER]
       do end
end

VYCQ(3):

Is B[INTEGER,DOUBLE] conform to A[DOUBLE,INTEGER]?

The answer is no and thus the code regarded as valid.

Summary:

  • correct result: valid
  • old rules: valid
  • wildcard rule: valid
  • complex rule: valid

Example 6

This is the second example which is valid under the current rules. The code is valid as the Conversion principle cannot possibly be violated.

  • eweasel test: convert-to-base-class-inherited
class A[G]
end
 
class B[G->INTEGER_REF]
inherit
      A[G]
convert
   to_a: {A[DOUBLE]}
feature
   to_a: A[DOUBLE]
       do end
end

VYCQ(3):

Is B[INTEGER_REF] conform to A[DOUBLE]?

The answer is no and thus the code regarded as valid.

Summary:

  • correct result: valid
  • old rules: valid
  • wildcard rule: invalid
  • complex rule: valid

Understanding the matter

If we take the inheritance hierarchy of an Eiffel system it can be abstracted to a directed acyclic graph.

The following illustration shows where conversion is valid and where not.

Possible solution

Instead of restricting VYCQ(2) and VYCP(2) to non-generic types we allow generic types too. As VYC*(2) is even using the notion of current type, it might indeed be possible that it was the authors original intention.

We define an additional function FTN which replaces every formal generic with another type:

  • By a wildcard type, which is conform to anything if the formals constraint type is not frozen.
  • By the (single) frozen type which occurs in the constraint of the formal.

The wildcard type virtually makes the conformance check for this formal obsolete, as the result is always true.

We define CTC as the type obtained from CT by replacing every formal generic parameter by its constraint.

The new version could look like this:

  • VYCP'(2) FTN(SOURCE) does not conform to CT
  • VYCQ'(2) FTN(CT) does not conform to TARGET

To complete and take the


New rule applied to examples

Example 1 for VYCQ'(2):

Is A[WILDCARD] conform to A[G]?

The answer is yes and the validity rule is violated, which is good.


Example 2 for VYCQ'(2):

Is A[WILDCARD] conform to A[STRING]?

The answer is yes and we reject the code.


Example 3 for VYCQ'(2):

Is A[WILDCARD,WILDCARD] conform to A[G,G]?

The answer is again yes and therefore the code not valid.


Example 4 for VYCQ'(2):

 Is B[WILDCARD] conform to A[STRING]?

As B only inherits from A[ANY] the answer is no and we're fine.


Example 5 for VYCQ'(2):

Is B[INTEGER,DOUBLE] conform to A[DOUBLE,INTEGER]?

The answer is no and therefore the code valid.

Example 6 for VYCQ'(2):

Is B[WILDCARD] conform to A[DOUBLE]?

The answer is ues and therefore the code valid. But it should be invalid because the constraint INTEGER_REF and the fact that DOUBLE is frozen makes it impossible to create a type which satisfies both, the conformance to INTEGER_REF and to DOUBLE.