Great examples and walkthrough. I love using lambdas in constructor arguments for concrete class implementation. Really cuts down on the code and noise.
Nice! Love it! The level int could be replaced with an Enum. This will intorduce more readable names for it like (Title, Subtitle, etc.) as well as removing the need to check the parameter.
Hey, good thinking DeliOZzz! Pushing that validation from a runtime check to a compiler check (by means of an enum) would have been a great way to deal with it! 👍
Hey, thanks for the recommendation! I'm planning to get into DSLs a little bit when I cover the Builder Pattern, but then also a separate video (or series) about the tactical approach to creating a DSL.
It sure will! I'm hard at work scaling up the illustrations from the earlier chapters so they'll look good in a print resolution. Hoping to have the books ready in just a few months.
Ah, I think you're referring to 17:24? Yes, maybe I should have kept going with the value classes at 17:52... all the way down to the text, url, and level values.
I meant that on line #4 of the code 17:28 you have swapped the parameters in createLink , which are text and url in lambda usage url and text. When you accept parameters from a lambda function, you can name them as you like, but in this case you get the wrong values because you have incorrectly renamed or swapped the places I meant to avoid this, they just might not be of type String but of value class. I saw that you offer an interface for Element and value class for Paragraph, but I meant for text and url so that they can't be swapped in the lambda function like you did on line 10 and line 16The method you describe as design pattern factory is great at implementing Kotlin.But sometimes when working with many strings, so as not to swap the places of the parameters it is used value class, because lambda functions, unlike normal functions, do not work on the principle of parameter naming. Sorry for my bad english.
Okay, understood, thanks! I wasn't sure about the timestamp "15:21" in your original comment, but I think that might have just been a typo. We're tracking with each other now! 👍
@typealias Sorry for the mistake in timestamp. This happened because I transferred the video from the phone to the chromecast on the TV, and then I wrote the comment from the phone and it put the wrong time.I hope I have clarified the error in the lambda function. I suggest you test it to find out that the text and url values will be swapped..
I have a question about Java it self. Projects like Valhalla, Lilliput, Leyden etc are going to influence Kotlin too or they are completely irrelevant to Kotlin?
Hi Gregan! I haven't looked deeply into Lilliput or Leyden, but it looks like they'll affect the JVM, so I expect we'll see similar performance and memory improvements when Kotlin is running on the JVM. For Valhalla, it's possible that Kotlin's value classes will end up utilizing Java value types (at which point we'd no longer need the `@JvmInline` annotation on our value classes when targeting JVM). You can read more about that idea here - github.com/Kotlin/KEEP/blob/master/notes/value-classes.md#project-valhalla. That documentation is a few years old at this point, but as far as I know, it's still likely that things would go in that direction.
Hmm... well, if you're running Kotlin on the JVM you can _tune_ the garbage collector... so if you don't want GC to run, I suppose you could give it more memory than your app or script will need for the duration of its run... Can you explain a little more about what you're trying to accomplish?
Ah, the confusion is probably because Kotlin/Native does have its own GC. If you're using Kotlin/Native instead of JVM, you can see this link for more info about disabling it: kotlinlang.org/docs/native-memory-manager.html#disable-garbage-collection
Why would you even need these patterns in Kotlin? I mean they were mostly invented when languages like Java didn't have a lot of syntax tooling. Just use DSL, it will be cleaner and easier.
We'll get to DSLs soon, but they solve a slightly different problem - if we want to construct a Document object all in one place, then a builder DSL would be a solid choice. If we want the user to be able to add/remove elements after the Document object is already constructed, then a factory tends to be more helpful.
Hi Dave, I'm so thankful for your time and effort, I like your content so much. Thanks!
Hey Jose, you're most welcome! I'm glad you've been enjoying it
It’s a mind-blowing explanation of how Kotlin simplifies these patterns. And I love the way you explain complex concepts so easily.
Thanks so much! I'm glad to hear that the explanation worked well!
"Seeds of complexity". Love this quote!
Thanks Dave, these videos are so good. I have been using Kotlin in old Java ways, not really using the language features.
Love this series
Man, you are the best teacher ever!
That's very kind of you! Thank you so much!
Brilliant video as always, thanks for the great content!
Great tutorial! It is easy to understand for beginners like me. Thank you Dave.
You're most welcome, Thura! I'm glad you enjoyed it!
Great video, keep going! Wait for more!
Thanks, Marcin! I'll keep at it! 👍
Your videos are crazy, you are cazy! In a good way!
Great examples and walkthrough. I love using lambdas in constructor arguments for concrete class implementation. Really cuts down on the code and noise.
Thanks so much, Gile! Yes, I love that you can still use trailing lambda syntax, even with constructor calls!
Nice! Love it!
The level int could be replaced with an Enum. This will intorduce more readable names for it like (Title, Subtitle, etc.) as well as removing the need to check the parameter.
Hey, good thinking DeliOZzz! Pushing that validation from a runtime check to a compiler check (by means of an enum) would have been a great way to deal with it! 👍
great learning experience, thank you Dave!
Hey Dave thanks for this great series I appreciate that.
I asked you for kotlin dsl series
including convention plugins and etc pls
Hey, thanks for the recommendation! I'm planning to get into DSLs a little bit when I cover the Builder Pattern, but then also a separate video (or series) about the tactical approach to creating a DSL.
counting on you❤
hey Dave will your Kotlin book be available to buy as paperback inthe future?
It sure will! I'm hard at work scaling up the illustrations from the earlier chapters so they'll look good in a print resolution. Hoping to have the books ready in just a few months.
15:21 createLink function (line 4) have parameters text and url swapped in usage.
I recommend using a value class instead of a String in this case.
Ah, I think you're referring to 17:24? Yes, maybe I should have kept going with the value classes at 17:52... all the way down to the text, url, and level values.
I meant that on line #4 of the code 17:28 you have swapped the parameters in createLink , which are text and url in lambda usage url and text. When you accept parameters from a lambda function, you can name them as you like, but in this case you get the wrong values because you have incorrectly renamed or swapped the places I meant to avoid this, they just might not be of type String but of value class. I saw that you offer an interface for Element and value class for Paragraph, but I meant for text and url so that they can't be swapped in the lambda function like you did on line 10 and line 16The method you describe as design pattern factory is great at implementing Kotlin.But sometimes when working with many strings, so as not to swap the places of the parameters it is used value class, because lambda functions, unlike normal functions, do not work on the principle of parameter naming.
Sorry for my bad english.
Okay, understood, thanks! I wasn't sure about the timestamp "15:21" in your original comment, but I think that might have just been a typo. We're tracking with each other now! 👍
@typealias Sorry for the mistake in timestamp. This happened because I transferred the video from the phone to the chromecast on the TV, and then I wrote the comment from the phone and it put the wrong time.I hope I have clarified the error in the lambda function. I suggest you test it to find out that the text and url values will be swapped..
I have a question about Java it self.
Projects like Valhalla, Lilliput, Leyden etc are going to influence Kotlin too or they are completely irrelevant to Kotlin?
Hi Gregan! I haven't looked deeply into Lilliput or Leyden, but it looks like they'll affect the JVM, so I expect we'll see similar performance and memory improvements when Kotlin is running on the JVM. For Valhalla, it's possible that Kotlin's value classes will end up utilizing Java value types (at which point we'd no longer need the `@JvmInline` annotation on our value classes when targeting JVM). You can read more about that idea here - github.com/Kotlin/KEEP/blob/master/notes/value-classes.md#project-valhalla. That documentation is a few years old at this point, but as far as I know, it's still likely that things would go in that direction.
@@typealias Super Thanks!
Hello!
It's possible to write Kotlin in a way to never call the GC?
Hmm... well, if you're running Kotlin on the JVM you can _tune_ the garbage collector... so if you don't want GC to run, I suppose you could give it more memory than your app or script will need for the duration of its run... Can you explain a little more about what you're trying to accomplish?
@@typealias Sorry, I had thought that GC is inside Kotlin, now I understood.
Thank.
Ah, the confusion is probably because Kotlin/Native does have its own GC. If you're using Kotlin/Native instead of JVM, you can see this link for more info about disabling it: kotlinlang.org/docs/native-memory-manager.html#disable-garbage-collection
@@typealias Thank.
Why would you even need these patterns in Kotlin? I mean they were mostly invented when languages like Java didn't have a lot of syntax tooling. Just use DSL, it will be cleaner and easier.
We'll get to DSLs soon, but they solve a slightly different problem - if we want to construct a Document object all in one place, then a builder DSL would be a solid choice. If we want the user to be able to add/remove elements after the Document object is already constructed, then a factory tends to be more helpful.