using concurrent
class Tree{}
class AdvancedTree:Tree{}
mixin HasTree{
virtual Tree tree(){
Actor.locals["tree"]
}
}
mixin HasAdvancedTree : HasTree{
override AdvancedTree tree(){
HasTree.super.tree
}
}
class Leaf : HasTree{
}
class AdvancedLeaf : Leaf,HasAdvancedTree{
}
Compiler output:
Test.fan(21,1): Inherited slots have conflicting signatures 'testPod::HasTree.tree' and 'testPod::HasAdvancedTree.tree'
brianThu 19 Jul 2012
A class can have only one slot called tree. So if you have two different super types that declare tree with conflicing signatures then you can't inherit from those two things at the same time.
AkcelistoThu 19 Jul 2012
This is same slot. I override it!
So if you have two different super types ...
This is not different super types. One type extends other.
brianThu 19 Jul 2012
Yeah but in that case it is complex because you are have different return signatures. It is true covariantly it might all actually work, but in the Java VM covariance is just a facade by implementing casts under the covers. In the end your subclass can't override two methods with the same name which differ by return signature.
qualidafialThu 19 Jul 2012
I thought the JVM achieved covariance through bridge methods?
brianThu 19 Jul 2012
When I investigated (which was 1.6 probably), they used same technique as generics - just inserting a cast, but you have to actually ensure that your method return types are exactly the same. In .NET they actually allow real covariance in the intermediate code.
Akcelisto Thu 19 Jul 2012
Compiler output:
brian Thu 19 Jul 2012
A class can have only one slot called
tree
. So if you have two different super types that declaretree
with conflicing signatures then you can't inherit from those two things at the same time.Akcelisto Thu 19 Jul 2012
This is same slot. I override it!
This is not different super types. One type extends other.
brian Thu 19 Jul 2012
Yeah but in that case it is complex because you are have different return signatures. It is true covariantly it might all actually work, but in the Java VM covariance is just a facade by implementing casts under the covers. In the end your subclass can't override two methods with the same name which differ by return signature.
qualidafial Thu 19 Jul 2012
I thought the JVM achieved covariance through bridge methods?
brian Thu 19 Jul 2012
When I investigated (which was 1.6 probably), they used same technique as generics - just inserting a cast, but you have to actually ensure that your method return types are exactly the same. In .NET they actually allow real covariance in the intermediate code.