0

I am struggling to understand the interplay of multiple inheritance with replication and polymorphism. Please consider the following classes forming a classical diamond pattern.

deferred class A
  feature 
    a  deferred end
  end

deferred class B
  inherit A
    rename a as b end
  end

deferred class C
  inherit A
    rename a as c end
end

class D
  inherit 
    B
    C
    select c end
feature
  b do print("b") end
  c do print("c") end
end

If I attach an instance of D to an object ob_as_c of type C, then ob_as_c.c prints "c" as expected. However, if attach the instance to an object ob_as_b of type B, then ob_as_b.b will print also print "c".

Is this intended behaviour? Obviously, I would like ob_as_b.b to print "b".

beckni
  • 3
  • 3

2 Answers2

1

Just describing the actual behavior in EiffelStudio which may differ from the actual ECMA specification.

What is happening is that without the select both b and c corresponds to a version of a. The compiler would complain that you have 2 routines with different name but same version. By using `select' you are fixing the error and telling the compiler that for dynamic binding the version to use is c and this is regardless of the type of the target, it is based on the type of the target at runtime.

Emmanuel Stapf
  • 213
  • 1
  • 7
  • Thank you for the explanation. Unfortunately, this makes Eiffel's inheritance features much less useful to me. – beckni Sep 14 '15 at 13:00
  • 1
    Regarding ECMA specification: Doesn't 8.16.11, "Definition: Dynamic binding version", state that in my example `ob_as_b.b` should print "b" since there is only an conformace path from D to B and feature b of D is the inherited feature b of B? The select clause should only be relevant when there are two or more conformance paths. – beckni Sep 14 '15 at 20:06
0

(Cosmetics: the spelling is "deferred". Otherwise it won't compile!)

"select" only affects the semantics of a call whose target is an entity declared with the repeated ancestor type, here A, since in this case we need a disambiguation. For entities of type B, C or D there is no ambiguity, so the normal rules of polymorphism and dynamic binding apply: for the same target object, it does not matter whether the entity (the name in the program) is declared of type B or C.

-- Bertrand Meyer

Bertrand Meyer
  • 1
  • What you describe is the behavior that I expected and that, I think, is specified in 8.16.11 in the ECMA standard. However, this is not what happens in EiffelStudio: In my example, the result of `ob_as_b.b` depends on the select clause in D, even though B is not a repeated ancestor of D. (Btw, I fixed the embarassing typo.) – beckni Sep 25 '15 at 18:48