In subclasses, one often needs to explicitly cast ...

# getting-started

[David Kubecka]

In subclasses, one often needs to explicitly cast a supertype to the type required by the current context, e.g.

class Cat : Animal {
  override var owner: CatOwner

  override fun switchOwner(owner: AnimalOwner) {
    owner = owner as CatOwner
  }
}

The cast to CatOwner is semantically redundant because it's quite clear what the resulting type should be, only the compiler can't/shouldn't guess it. Still, these casts soon seem like a boilerplate (especially with more complex generic types) so I devised the following helper function:

inline fun <reified TOut : T, T : Any> T.asTOut() = this as TOut

The usage would then simply be

override fun switchOwner(owner: AnimalOwner) {
    owner = owner.asTOut()
  }

This basically emulates what the compiler does when inferring generic parameter types. Of course, the difference in my example is that it's generally unsafe (that's why the compiler doesn't do it automatically).

What do you think about this? Neat or horrible?

[Sam]

The cast is inherently unsafe, so I don’t like the idea of hiding it inside a helper method

[Sam]

I think I would rather invest the time in finding a design that avoids the unsafe cast in the first place

[Klitos Kyriacou]

Perhaps we could do with covariant function parameter types? (For example, Eiffel has them.)

[Sam]

@Klitos Kyriacou that sounds interesting, can you give an example? I struggle to see how it would work with polymorphism

[Klitos Kyriacou]

It's all explained at https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Covariant_method_parameter_type

[David Kubecka]

Interesting indeed. As stated in the quoted section, the Eiffel approach isn't typesafe. OTOH the problem is real - it's IMO not a coincidence that I face that exact same issue in my production app at several places. It seems that neither solution is ideal. With Eiffel, the code is inherently type unsafe, but you don't need any casting. With Kotlin (and most other statically typed languages), it's the opposite. Not sure what is better though...

[ephemient]

interface Animal<A : Animal<A, O>, O : Owner<O, A>> {
    var owner: O
}

interface Owner<O : Owner<O, A>, A : Animal<A, O>>

class Cat : Animal<Cat, CatOwner> {
    override var owner = CatOwner()
}

class CatOwner : Owner<CatOwner, Cat>

may be overkill depending on the use case, but this forbids Cat().owner = notCatOwner() at compile time instead of a runtime cast

[David Kubecka]

Yeah, I tried that at first but that is a rabbit hole once you have more aspects which translate to additional generic parameters in this design.

[David Kubecka]

Basically, I decided that a few "internal" casts constitute a more pragmatic approach than the clean solution with generics where the types quickly become repetitive and unreadable.