Intersection Types in Kotlin

Рет қаралды 3,466

Күн бұрын

Let's take a look at Kotlin's support for non-denotable intersection types, and how we can even pass them to functions with compile-time type checking!
✨ New to Kotlin? Start here: typealias.com/start/
... or pick up the new Leanpub Edition! book.typealias.com/
🚀 I just launched a new email newsletter!
Sign up here: newsletter.typealias.com/
☕ Get your own Mr. Grumpy Recalcitrant Man mug here:
www.redbubble.com/i/mug/Mr-Gr...
00:00 State of Intersection Types in Kotlin
00:45 Introduction to Intersection Types
01:30 Example Code Walkthrough
02:30 Runtime Type Check Approach
05:30 Compile-Time Type Check Approach
07:05 Alternatives and Trade-Offs
#kotlin #androiddevelopment

Пікірлер: 33

@typealias 4 ай бұрын

What do you think - should Kotlin support denotable intersection and union types?

@SAmanteaColls 4 ай бұрын

If it doesn't cost me anything in compilation or runtime performance then yes absolutely up for denotable intersection types.

@theexaustedslime 2 ай бұрын

Given they're already supported it seems a shame not to have them be denotable, but you'd have to be careful with the syntax to steer people away from confusing it with multiple inheritance. I also wonder if there are good arguments against passing around A & B & C rather than RealType: A,B,C. I also want discriminated union types, but it seems unlikely.

@JonWolski 4 ай бұрын

At first I thought, “you need something like Rust’s trait bounds or Haskell’s type constraints.” Then you showed exactly that. (In fact Rust’s `where` syntax is remarkably similar.) I don’t work on the JVM much anymore, but if I did, I’d choose Kotlin for its more complete data type algebra.

@typealias 4 ай бұрын

Oh, cool! I'll enjoy getting a closer look at how those language features work compared to this - especially if / how they apply to function results instead of just function arguments. 👍

@PeteC62 23 күн бұрын

I absolutely use intersection types in Typescript, often just as a way of extending a type because I prefer to use *type* over *interface* (so your combination interface was the first solution that came to my mind for Kotkin). But what I'd love to see even more in Kotlin is union types!

@justADeni 4 ай бұрын

Great video! And I love the Mr. Grumpy Recalcitrant Man 😆

@typealias 4 ай бұрын

Thank you! I'm glad you like Mr. Grumpy Recalcitrant Man! I think we can all relate to him. 😁

@danielpitts6913 4 ай бұрын

Another way to do this is to use the `context` feature (needs to be enabled in the compiler options). The syntax isn't as nice for this use-case, but makes sense for other ones. context(Named, Addressable) fun process() { println("Processing... $name at $address") } fun main() { User("John Doe", "123 Main St.").run { process() } }

@typealias 4 ай бұрын

Context receivers! Yeah, it's been a while since I checked in on them. Definitely similar! 👍

4 ай бұрын

That's exactly what I'm looking for ❤. The other part of my problem was to pass an anonymous object as parameter to the function call. That was what worked for me: // calling process(item = object : Named, Addressable { override val url: String get() = TODO() override val name: String get() = TODO() })

@typealias 3 ай бұрын

Ah, thanks for pointing that out, Vinícius! Yes, anonymous classes can indeed be created for multiple interfaces at the same time! That could be helpful for others watching the video.👍

@easybusinessou 3 ай бұрын

Great video, keep it up! We're always looking forward to your content and eagerly await a tutorial video for your amazing book 'Kotlin: An Illustrated Guide'

@typealias 3 ай бұрын

Thanks so much! New video coming very soon!

@stephenmorse8207 3 ай бұрын

Nice video, thanks Dave! I have used the "where" constraints before, but never realized they could be used for type intersections. Based on the definitely non-nullable generics syntax, I think native intersection support is desired by the language maintainers, but I imagine it's low in the priority list.

@typealias 3 ай бұрын

Thanks, Stephen! Yeah, a lot of new features are in a holding pattern until Kotlin 2.0 comes out, which I suspect will land sometime between now and KotlinConf in May. In last year's keynote, they mentioned some features they were planning to deliver after K2 arrives, and Denotable Intersection Types wasn't on that list... but it does have more votes than some of the things that _were_ on the list. So, we'll see...

@cnkaptan 4 ай бұрын

I was reading your blog from day 1 and right these videos, it is amazing man really, with your draws or these animations. you are the best

@typealias 4 ай бұрын

Ah, thanks so much! I appreciate it! 😁

@jjhoninatan55sabadi 4 ай бұрын

I liked this approach!!! In cases that need more than 2 interfaces, and to create a new interface that envolve all of them it's a little strange. Great content!!

@typealias 4 ай бұрын

Great, thanks so much! I'm glad it was helpful for you! 😁

@lewstherintelescope 4 ай бұрын

I go back and forth on whether I want intersections (and unions) to be easily denotable in Kotlin specifically or not. On the one hand, they can be useful like you showed. On the other, I think Kotlin has kind of suffered from having too many features thrown in that are sliiightly different from one another and could use a bit of trimming + condensing into deeper features first, _then_ take a look at which new features are still needed. (Of course that's not going to happen in practice, removing any non-experimental feature would be a huge breaking change.) I'm also curious how this is represented on the JVM, I'd guess it probably just chooses the nearest superclass of both types or something?

@typealias 4 ай бұрын

Yeah, that makes sense. I've definitely seen how some programming languages (that have been around longer than Kotlin) have ended up with many features that are similar to each other, or that allow so many varying approaches to the same thing, that the language starts to lose its identity, and there's no clear consensus from the developer community about how to solve the same problems. FWIW, Kotlin _has_ successfully deprecated quite a few behaviors and stdlib functions... but it's a pretty long lead time, and like you said - breaking changes are a big consideration. The implementation on JVM is pretty straightforward - the object is just cast to the appropriate type before calling a function on that type. For the example in this video, it looks like this: "Refreshing data for " + ((Named)item).getName() + " at " + ((Addressable)item).getUrl();

@safionweb 3 ай бұрын

Amazing content man!

@typealias 3 ай бұрын

Thanks - I appreciate it!

@writerchris2j1984 4 ай бұрын

I like your work thank you!

@typealias 4 ай бұрын

Thanks so much! 🙂

@watcher-ik4gvr 2 ай бұрын

I think you are know Kotlin better than Kotlin inventor himself

@typealias 2 ай бұрын

That's kind of you to say! Breslav and Elizarov are some incredibly knowledgeable developers, and I'm just thankful they created a language that I enjoy so much!

@MezPahlan 4 ай бұрын

Great video explainer 😊. I'm trying to do something similar but I think different. Is this the same as Union types? I want to create a function that accepts / returns either String Boolean Integer or my own type. Any seems to be my only option at the moment plus runtime checks.

@typealias 4 ай бұрын

Thanks so much! 🙂 Yes, union types are related but different, as you noted. Kotlin's type system doesn't currently support union types at all, but there are a few things you can consider using in order to avoid the Any type. In certain cases, some good old fashioned function overloads will do the trick. It definitely results in additional boilerplate, though, since you have to define a function for each type. Another option to consider is an Either type, like the Arrow library provides. This is helpful in cases where you've only got _two_ types... but since your use case has four, it wouldn't be as helpful there. Anyway, not sure if those are helpful for your particular use case. Kotlin has an open ticket for considering denotable intersection and union types here: youtrack.jetbrains.com/issue/KT-13108. You can vote on it, add your use case, and watch it for updates!

@thebigboi5357 3 ай бұрын

To add, custom union types (such as Arrow’s Either type, or Michael Bull’s Result type) can be created with a combination of sealed classes, generics, and extension functions

@einsjannis 4 ай бұрын

The fact that you even considered the idea of just using the "Any" type is really bad, especially that it took up a major part of the video.

@typealias 4 ай бұрын

My goal in each video is to lay a solid foundation of understanding for the concept, and that doesn't happen when you simply jump to the "best" solution. It requires wading through worse solutions, talking through the problems with them, and gradually refining them toward better solutions, so that by the end we understand why each solution is more optimal or less optimal compared to the others. If you can't spare the three minutes that the Any section took up in this video, that's fine, but future videos here will have a similar pace.