More concise "Either"?

[nottheoilrig]

@nickallendev

If those 3rd part classes don’t have any common ancestor defining those common methods, then I don’t think there is a more concise way.

That’s my goal: effectively to create FormParser.BaseContext, or take a third-party class (un-)hierarchy and introduce a common ancestor/interface/trait, so I can run the same evalLine() logic on either instance.

Thanks for confirming that anything more concise would (currently) require a common ancestor, however I’d then use that ancestor directly if it existed:

fun evalLine(ctx: FormParser.BaseContext) {
  val instructions = ctx.instructions()
  [...]

I sealed the interface in the example only hoping I wouldn’t need to enumerate the common members.

Philosophically I’m dealing with two different issues I think:

1. I was surprised there isn’t a concise way to express the common members of a set of types, i.e. “union type”.

   I found the following quote compelling on the one hand and principled at the expense of convenience on the other:

   @gidds

   In the example above, while both First and Second have methods called speak(), they’re not the same method. (Unless both classes implement some interface defining speak() – but then you don’t need union types, as you can simply use that interface instead.)

   Sounds like this does come up in practice but has already been thoroughly debated.

2. When third-party types aren’t interfaces, there isn’t a concise way to extend an existing (un-)hierarchy with a type for the (explicit) common members (only interfaces can be delegated to).

   Maybe a use case for KT-21955 delegating to a class?

   Adding already-implemented types directly (without delegation/wrapper, i.e. “extension types”) has also been thoroughly discussed.

Thanks again for your help!