Talk:Typing policy

From SmartEiffelWiki

Table of contents

Rule 6

Is rule 6 from your typing policy correct? It tells that G[A1,A2,...,An] (implicitly) inherits from G[B1,B2,...,Bn] if for each i holds: Bi inherits Ai. It seems to me that the part about Bi and Ai should be differently formulated: if there is at least one i for which Bi inherits Ai holds, and for all j /= i it holds that Bi is the same type as Ai or Bi inherits Ai.

In my opinion this would be sufficient to allow polymorphism. --Andy

"require then"?

As you introduced "insert" I was surprised that the SmartEiffel team did not add something like "require then" as precondition clause. The meaning of "require else" is to correctly reuse features if polymorphic assignements are possible. This is not the case for "insert" and thus it could be possible to allow stronger preconditions in the absence of polymorphic assignements. --Andy

Yes, I agree with you. --Cyril 07:14, 7 Mar 2006 (CET)

Sorry, but I have to correct my comment. It is not possible because of rule 5. I'll show it on the smallest example I found:

 class A feature
  x (i: INTEGER) is do ... end
 end
 class B insert A redefine x end feature
  x (i: INTEGER) is
   require then
    i > 0
   do
    ...
   end
 end
 class C [X -> A]
 feature a: X
  There is a feature with the call: a.x(-1)
 end

As class C [X -> A] (and also the derivate C [B]) is a client of A it is allowed to call a.x(-1), which is not valid for C [B]. This could be avoided by another formulation of rule 5. From a design point of view require then and ensure else would be interesting. As a consequence someting like invariant else could be introduces. At the end it would be another language... (But interesting :-)...) --Andy

Rule 6 changed

I just corrected the description, which was inconsistent with what we had decided and implemented. --FM 18:15, 3 Mar 2006 (CET)

Bug in Eiffel Specification?

I found a case in which the precondition of a feature can be made stronger in its subclass. It has no run-time effect, but should not be possible because of polymorphic assignments. A client would not be guaranteed that all calls are legal.

 class K feature
  a (i: INTEGER) is
   do
    ...
   end
 end
 class L inherit K redefine a end feature
  a (i: INTEGER) is
   require
    i > 0
   do
    ...
   end
 end

Here a client of K can not be sure that all calls to feature 'a' are valid. But every client should be allowed to only respect the interface of the classes he/she is using and not additionally to have a look at the subclasses.

A possible alternative view would be: In feature 'a' of class K we have the non-written precondition require True , as every call is valid. Thus {L}.a could only use require else... --Andy

That's not a new problem. There have been quite hot talks in the past as to wether not providing a require in the first hand is equivalent to require True or not. In practice, it is not, and leaving that door open leaves good expressiveness. Anyway that's why introducing require then does not introduce any new problem. --Cyril 08:49, 22 Mar 2006 (CET)

In my opinion a programming language should restrict the programmer to use its concepts correctly (in as many situations as possible). At the moment this is not the case because of the known problem. An introduction of require then would further complicate the situation. But as I see it at the moment there is a possibility to correctly use require then (only in combination with insert). As a consequence one could remove the known problem (no require becomes require True). I don't know wheter you are interested in it. I don't want to waste your time. --Andy 10:48, 23. Mar 2006 (CET)