Ambiguous Inheritance

[Tom Kaitchuck]

If I define the following class:

class CopyingList<T>() satisfies List<T> {

variable List<T> impl = [];

shared actual T? getFromFirst(Integer index) {

return impl.getFromFirst(index);

}

shared void add(T element) {

impl = [element, *impl];

}

shared actual Integer? lastIndex => impl.lastIndex;

}

I get the errors:

May not inherit two declarations with the same name unless redefined in subclass: equals is defined by supertypes Identifiable and List.

Member hash is inherited ambiguously by CopyingList from Identifiable and another subtype of Object and so must be refined by CopyingList.

May not inherit two declarations with the same name unless redefined in subclass: hash is defined by supertypes Identifiable and List.

Member equals is inherited ambiguously by CopyingList from Identifiable and another subtype of Object and so must be refined by CopyingList.

I don't understand why this is ambiguous. My assumption would be that List's implementation would take president over Object's. 

[John Vasileff]

Tom, there’s actually another class in there.

`CopyingList<T>` implicitly extends `Basic`, and `Basic` satisfies `Identifiable`. Neither `Object` nor `List` satisfy `Identifiable`. Therefore, `CopyingList` inherits `equals` from both `Identifiable` and `List`, with neither refining the other (both do of course refine `Object.equals`, but that doesn’t help with the ambiguity.)

John

--
You received this message because you are subscribed to the Google Groups "ceylon-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-users...@googlegroups.com.
To post to this group, send email to ceylon...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/1b37d70c-9e86-40ff-b7b0-aa51ce2d5da9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gavin King]

The usual way I solve this, by the way, is to make CopyingList extend
Object directly. You don't usually need identity for lists...

> https://groups.google.com/d/msgid/ceylon-users/42726593-A288-4BE3-97E6-D6A7CBA4D686%40vasileff.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
Gavin King
ga...@ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

[John Vasileff]

`CopyingList` should be a reference type though, right? It has a `variable` member, and will have reference type semantics. It’s really more of a mutable list.

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/CAP7PoCec-C983kOELNjokn3R4sLaKRTte1UFT%3DTeMFD%3D4ZFb-Q%40mail.gmail.com.

[John Vasileff]

BTW, I’ve been meaning to write up a feature request to deprecate `variable`s in non-identifiables, so that we can have value types outside of the language module. But actually, the spec already has this:

> If a class declares or inherits a variable reference, it must (directly or indirectly) extend the class Basic defined in ceylon.language.

John

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/516279EF-6127-4D78-9A19-4C5491082716%40vasileff.com.

[Gavin King]

Ah so that language is still there. I thought it had been removed at some stage. It's not enforced by the typechecker.

Sent from my iPhone

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/32D36BEC-FF16-4375-9131-B2245906D70C%40vasileff.com.