Great video as usual! Looking back, I used the implicit switching between extension and non-extension functions many times before without even realizing it! Also didn't know you could take references to property setters/getters, that's pretty neat!
Every time I think I will know everything in the video, you surprise me! I've always wanted to know if using these types of references are we doing any kind of reflection or not, since the symbol is the same
If you don't explicitly specify a type (e.g., `val x = ::countWords`), then a function reference will be one of the `KFunctionN` types, which gives you access to reflection properties and functions. But unless you've got the `kotlin-reflect` library added to your project, you'll really only have access to the `name`. Stay tuned - I've got a video queued up that explains all of this further... won't be the next video, but probably the one after that.
I like that you use one line property delegation by: val length get() = text.length I switched to an even shorter form: val length by text::length Advantage is that it is still one liner for var properties.
really interesting one. Some things are really ez in kotlin, but some things are blewing my mind still to this day. Thank you Dave. Really Gucci stuff.
This video is incredible ! I love your way of explaining things, we really feel you have a passion for that. I wanted to know what do you think about uniform function call from some languages like Nim ?
Hey, thanks so much, Fabrice! I appreciate your kind words! Although I haven't got much experience with languages that support uniform function call syntax, in concept I like the convenience of it. Of course, it's not always natural for the first parameter to be used as a receiver - e.g., `createUser(firstName, lastName, age)` would be confusing as `firstName.createUser(lastName, age)` - so regardless of whether the developer has to opt in to the "method" syntax or whether the language gives it to you out of the box, developers still need to use discretion. Have you got thoughts about it yourself?
@typealias thanks for your feedback ! I thought the same ! I implemented it for a language I am building (still far from finished because of the complexity of different features I joined together ^^') It's quite convenient since you can switch between a normal call (f(x)), it's "method call" (x.f()), it's pipe call (x |> f()) or his arrays versions (f#([x]), [x].f#(), [x] |> f#()). But when it's too convient, that can mean there is a potential problem. That's why I wanted to know how kotlin functions works to see if there is a benefit (security, efficiency, etc.) in the way it does things. Actually I don't really know🤔
Amazing video, thanks for sharing :) i have a question for the last example, using Lamdas with receivers u can pretty do everything extension function do ? If so what is the difference between them ?
Hey, thanks so much! The differences between a lambda with a receiver and an extension function are essentially the same as the differences between a regular lambda and a regular function. The biggest differences are that a lambda is an expression, the `return` works differently in a lambda than a function, and lambdas require type inference to determine a return type and receiver type. You'll see some of those differences demonstrated in next week's video.
Great video! Do you have any resources or plans on using Socket Servers within kotlin? After learning all these things i’m looking into sockets for sending “commands” between my projects to act upon!
Hey Stefano! I've used websockets with Ktor ( ktor.io/docs/server-websockets.html ) for that kind of thing, but pretty sure I'll end up updating those projects to use kotlinx.rpc ( github.com/Kotlin/kotlinx-rpc ) once that project is a little farther along. I showcased some of kotlinx.rpc in a livestream a few months back. You can jump to that segment here: ruclips.net/user/liveS_JKbmN_A8o?feature=shared&t=389
Just when I thought I knew everything about function types
Lots of neat little tricks just waiting to be exploited! 🙂
Great video as usual!
Looking back, I used the implicit switching between extension and non-extension functions many times before without even realizing it!
Also didn't know you could take references to property setters/getters, that's pretty neat!
Hey Dave!
I just wanted to say thank you for your wonderful book and videos. It really helps!
Thank you for your kind words, Aleksandr! I'm so glad you've been enjoying them.
All the things are neat. It would be great if you also explain each of such cool language features with a practical use case.
Every time I think I will know everything in the video, you surprise me! I've always wanted to know if using these types of references are we doing any kind of reflection or not, since the symbol is the same
If you don't explicitly specify a type (e.g., `val x = ::countWords`), then a function reference will be one of the `KFunctionN` types, which gives you access to reflection properties and functions. But unless you've got the `kotlin-reflect` library added to your project, you'll really only have access to the `name`. Stay tuned - I've got a video queued up that explains all of this further... won't be the next video, but probably the one after that.
I like that you use one line property delegation by: val length get() = text.length
I switched to an even shorter form: val length by text::length
Advantage is that it is still one liner for var properties.
Ooooh! I like that! I'm going to start using that! 😁
@@typealias I dont know if there is a difference in bytecode. But i believe in the power of the incredible compiler superman architects.
😂
Oh God that's so gorgeous!
Thanks!
Hey Dale! That's very kind of you. Thank you so much! 🎉
really interesting one. Some things are really ez in kotlin, but some things are blewing my mind still to this day. Thank you Dave. Really Gucci stuff.
Thanks so much! So many fun things to discover in Kotlin!
Damn that’s neat!
My mind was racing with practical applications to try out
Let me know what ideas you come up with!
This video is incredible ! I love your way of explaining things, we really feel you have a passion for that. I wanted to know what do you think about uniform function call from some languages like Nim ?
Hey, thanks so much, Fabrice! I appreciate your kind words! Although I haven't got much experience with languages that support uniform function call syntax, in concept I like the convenience of it. Of course, it's not always natural for the first parameter to be used as a receiver - e.g., `createUser(firstName, lastName, age)` would be confusing as `firstName.createUser(lastName, age)` - so regardless of whether the developer has to opt in to the "method" syntax or whether the language gives it to you out of the box, developers still need to use discretion. Have you got thoughts about it yourself?
@typealias thanks for your feedback ! I thought the same ! I implemented it for a language I am building (still far from finished because of the complexity of different features I joined together ^^')
It's quite convenient since you can switch between a normal call (f(x)), it's "method call" (x.f()), it's pipe call (x |> f()) or his arrays versions (f#([x]), [x].f#(), [x] |> f#()). But when it's too convient, that can mean there is a potential problem. That's why I wanted to know how kotlin functions works to see if there is a benefit (security, efficiency, etc.) in the way it does things. Actually I don't really know🤔
This is all cool and clever but if I ever saw this in a PR, I was kick it back.
Certainly a feature to be used judiciously
Wow thank you.
Amazing video, thanks for sharing :)
i have a question for the last example, using Lamdas with receivers u can pretty do everything extension function do ? If so what is the difference between them ?
Hey, thanks so much! The differences between a lambda with a receiver and an extension function are essentially the same as the differences between a regular lambda and a regular function. The biggest differences are that a lambda is an expression, the `return` works differently in a lambda than a function, and lambdas require type inference to determine a return type and receiver type. You'll see some of those differences demonstrated in next week's video.
@@typealias Thank u very much :), can't wait for next week vid
Great stuff, as usual! Thank you so much, Dave!
Thanks so much, Arthur!
Great video! Do you have any resources or plans on using Socket Servers within kotlin? After learning all these things i’m looking into sockets for sending “commands” between my projects to act upon!
Hey Stefano! I've used websockets with Ktor ( ktor.io/docs/server-websockets.html ) for that kind of thing, but pretty sure I'll end up updating those projects to use kotlinx.rpc ( github.com/Kotlin/kotlinx-rpc ) once that project is a little farther along. I showcased some of kotlinx.rpc in a livestream a few months back. You can jump to that segment here: ruclips.net/user/liveS_JKbmN_A8o?feature=shared&t=389
Thanks, from Vietnam😘
Thank you
You are the best man
TIL... Continue with the awesome content
This is fun 😀
you're good!!! 🤣
This is a little bit advanced for me
why not you become kotlin team lead, senior manage CEO , CTO and all other position at jet brains
Hey, that's kind of you to say! That'd be a lot of responsibility, though... so I'm going to stick to making videos! 🙂
but you will take kotlin to 1# loved lanuage
I just realized that I don't know shit about Kotlin functions...