i have a colleague who makes typealias for everyth...

# announcements

[tipsy]

i have a colleague who makes typealias for everything, like:

typealias Address = String
typealias Age = Int

when i see these typealiases used in signatures, i always assumed they're classes
is there a guideline on this? i personally find it very confusing, but it might just be because it's unfamiliar

[nfrankel]

it’s very OOP 🙂
i’d say use inline classes
and if before kotlin 1.3, use type aliases
then the migration path will be very very sweet
as for me, i use mainly type aliases when i’m too lazy to define a proper class
and i have tons of generics
like
typealias Cache = Map<String, Any?>

[tipsy]

yeah, i'm fine with that type of typealias, it's just when i ctrl-click and see "oh, it's just an int" that i get confused

[Daniel]

Using primitives for business code is still pretty bad most of the time, even when they are renamed 😉

[napperley]

The most common use case for typealias is for condensing complex signatures. Below is a example ( https://gitlab.com/gui-vista/guivista-gui/blob/master/src/linuxX64Main/kotlin/org/guiVista/gui/widget/widget_base.kt#L261 ) from the GUI Vista - GUI library:

typealias GrabFocusSlot = CFunction<(widget: CPointer<GtkWidget>, userData: gpointer) -> Unit>

[Mike]

I would agree with others. I suspect your colleague's intent is to have stronger typing of things to reduce errors, BUT unfortunately typealias does not accomplish that particularly well.

As others have said, either creating a data class Address(val value:String) or even better, an inline class will ensure the type is enforced where it is used.

typealias is good for giving a descriptive name to a complex type, or a function/Lambda signature, but in the bytecode, the typealias name will not exist.

[napperley]

The Kotlin Coding Conventions should include some guidelines on using typealias.

[codeslubber]

They did just have a post about it on their blog. It was decent.

[Dico]

I think it's dangerous to say that inline class is "even better" than a data class. Only use inline class if you are aware of its behaviour. The only use case for inline class is performance. It is very very very easy to write code that will constantly box and unbox inline classes, leading to detrimental performance to a data class. @Mike
This happens when using the type as nullable, as a generic type, and even when comparing two values of an inline class for equality (non-unsigned ints at least, kotlin ~1.3.50)

[Dico]

The only reliable way that I know of to confirm that boxing is not happening is to use IntelliJ's "Show Bytecode" feature.

[Dico]

I'm not saying inline class is bad, just be cautious especially because of its experimental state (which is likely to be there for a long time)

[napperley]

Rob - Which blog post covered typealias?

[codeslubber]

@napperley https://medium.com/androiddevelopers/alter-type-with-typealias-4c03302fbe43

[Stephan Schroeder]

I’m definitely on team Inline Class on this one. With

typealias Username = String
typealias Password = String

the compiler won’t complain if you assign a Username instance to a Password field, e.g. if you mix up the order in a method signature

fun login(username: Username, password: Password) : AccountHandle

but with Inline Classes it will!

inline class Username(val value: String)
inline class Password(val value: String)

@Dico So I’d say there is more to Inline Classes than performance.
And I always thought Inline Classes were a mere compile-time construct, so there wouldn’t be any Boxing/Unboxing involved (the runtime type would be String). Did I get this wrong??

Final words: I myself wait for Inline Classes leaving experimental status before using them. Hopefully that’ll happen in Kotlin 1.4 which should come out soon (The KotlinConf opening keynote pinpointed the release of 1.4 to Spring 2020).

[Dico]

@Stephan Schroeder you get all the same functionality without the inline modifier (add data for equals checks). The inline modifier adds some restrictions and changes the code emitted by the compiler, the goal of which is to improve performance. Therefore, the only underlying reason to ever use inline is for improved performance. There is no other reason. As I explained though, it is easy to use it in a way that makes it detrimental to performance, and the compiler does not help you in any way to detect that.

[Stephan Schroeder]

@Dico ah ok, you’re coming from using a data class and than inline class is more performant, but I’m coming from just just the basic type (String in my example) and then using inline class will be more type safe (but exactly equal in performance) 😉

[Dico]

Yeah if you avoid using the type in most scenarios, you wont run into the issues. In your use case though, I would either use the parameter name in the call site or rely on IntelliJ's visual aid

[Stephan Schroeder]

I do actually like a type checker telling me when I’m wrong (sometimes I make bugs that should be shallow already for a single pair of eyes 😅), but not to the “wasteful” degree that I’d wrap a single value into a data class. I didn’t even think of that possibility before 😅 So yeah, inline class leaving experimental will be a good day for me 🙂

[codeslubber]

‘Premature optimization is the root of all evil.’ … every time you decide to not do something because of waste ask yourself if you’re stepping in it..

[Dico]

Nice quote

[codeslubber]

Of course it’s from Donald Knuth, should have said that.. 🙂

[Dico]

😁