> You have to be careful with type inference: if there's no way for the compiler to figure out what type you want from the call site, you'll get an error. I'd

> You have to be careful with type inference: if there's no way for the compiler to figure out what type you want from the call site, you'll get an error. I'd say that's a feature, not a bug :) > You might say this isn't OOP in the strictest possible sense I would say it's not OOP in any sense. Having one function implement all the different behaviours, and pick which one to run by switching on some data (in this case the class tag) is a classic example of being not OOP. As a bonus, this ignores dynamic dispatch (the only implementation is for `String`) and it's not polymorphic (the same code doesn't work for different types; instead we have different clauses for each type). This would be salvagable if `String::fromString` only enforced the type constraint, and dispatched to `T::fromString` to do the actual parsing, e.g. inline fun <reified T> String.fromString(): T { return when { T::class == String::class -> this else -> T::fromString(this) } as T } I'm not sure whether that would work or not (I've never written Kotlin), but I still think it's "messy" (monkey-patching methods on to classes, reimplementing dynamic dispatch manually, inspecting classes (via the equality check), going out of our way to prevent infinite loops, etc.)