Відео

Hey, thanks so much, Ronny! Glad you're happy with the production quality!

Hey, Hameed! Thanks so much! For the book, the objective was to get the reader to the point where he or she could be productive with Kotlin day-to-day, so I've intentionally left out some of the things that are mainly concerned with optimization (value classes are another feature that I love, but just didn't quite fit the objective, so I left them out). So, they won't be included in the Illustrated Guide - however, I'll still be writing (and drawing!) about Kotlin features as standalone articles on the website, and if there's enough interest in that topic, I'd be happy to write that one!

That's fantastic! I'm so glad you found it helpful!

Hey, that's great, Robert! Emacs is another one that I always felt had a good reputation among the more hardcore, elite developers, but I never got too far with it myself. Neat idea to use its navigation shortcuts since they also work in the terminal! I do sometimes get tripped up when trying to navigate in another app. 😅

Hey, thanks so much, Mario! Took a while for me to finish all the animation, but I'm happy with how it turned out. =)

Thanks so much Anton! Looking forward to seeing you there!

Hey, that's great! And I'm glad to hear that there's no timeout for the Ctrl key on the second press on Linux. I think I'd use that shortcut more if that were the case - I'll check Mac and see whether it happens there, too.

@@typealias Yeah, it would be annoying if it disactivated. Hope to meet you in KotlinConf btw!

Yeah, sounds great! Looking forward to seeing you there!

Hey, thanks so much, Renato! I'm really glad to hear that you've enjoyed the book!

You got it! 👍

Hey Ilian, thanks for reaching out! I think I understand what you're getting at - the earlier approach had an actual type (e.g., EmailValidator vs. UsernameValidator) whereas by the end, they're all just the same type - (String) -> Boolean, and we'd have to be careful to use the right validator on the right kind of value. If we want the compiler to enforce that, I'm thinking we could still keep the latter approach, but might consider using simple value classes for the types, and generics for the validators. Maybe something like this: ``` interface Value { val value: String } @JvmInline value class Email(override val value: String) : Value typealias Validator<T> = (T) -> Boolean val emailValidator: Validator<Email> = { it.value.contains("@") && it.value.contains(".") } class FormField<T : Value>(val name: String, val value: T, private val validator: Validator<T>) { fun isValid() = validator(value) } fun <T : Value> Validator<T>.optional(): Validator<T> = { it.value.isEmpty() || this(it) } ``` I only included the value class for Email in the code here, but same idea for the Username and Password. This wouldn't add too much code, and having strong types for those values would usually be a good idea anyway!

@@typealias Thank you VERY much for the detailed answer.

Hey, thank you so much, Yan! I appreciate that!

Thanks, Peter! Yeah - I had played with Chain of Responsibility implementations recently, but I wasn't as happy with my ideas for it at the time, so I moved on to other patterns. I'll pull up my notes for it and see if I can look at it with a fresh perspective!

Thanks, Fabiano! I'm glad it's resonating so well with everyone!

Thanks so much! I'll add that to my running list of video ideas!

Thanks so much, Mike! I really appreciate that!

Oh wow, that's really great to hear - really glad that you're picking it up so quickly! I'll keep at it!

Thanks so much, Tony! It sounds like the format is working well for everyone, so I'll keep at it!

Thanks, Mankin! Yes, that's a good point. I think also as you start getting more distance between each enum entry, they start to feel less optimal as a choice. With the 5-parameter constructor that I had at the end of the video, they started spreading out a bit, but at least they did all fit on a single screen. But like you said, if we were to add a few more entries, it could start to become more difficult to keep up with them!

Hey, thanks Zeynep! I'm glad you enjoyed it! 🙂

Thanks - I've had a lot of requests to show shortcuts lately! My keyboard shortcuts are very customized, but most people are particularly interested in how to edit with multiple carets, so I'm going to cover that at the upcoming livestream. 👍

Yes, thanks Arthur! I probably should have just done that in the video - I can't think of any reason not to make the interface sealed here. 👍

Yes, good thinking, Pavlo! 👍

Maybe the term "state" here is closer to the term "state machine" than "object state"

While working on this video, I did feel like there's a bit of irony in that these state objects hold literally no state of their own. Yes - we basically made a finite state machine, and that's the sense of the word being used here. Maybe the term "State Pattern" was more intuitive back when the GoF book was written (I was just a high school kid writing QBasic at that point), but I can definitely see how it could be a confusing term these days!

There certainly is something nice about having all that code line up like that! 🙂

Transitions should be as simple as swapping the instance of state in the context. Unsupported operations should probably fail with IllegalStateException, a convenient way to throw it is to call the "fun error(message: Any): Nothing" function from the Kotlin standard library.

You certainly can use a class if you like! Even in the GoF Design Patterns book, they mention a lot of flexibility in how you can implement this one. If you've got states that have no instance variables of their own, you might prefer to keep them as singletons, as we're doing here, to avoid the cost of instantiating the additional objects for each user - the book points out that when we do that, the states are also very similar to flyweights from the Flyweight Pattern. For cases where that's not as important - which, these days, might be most cases - you can just instantiate a new state object each time, which would clean up the function signatures (because you wouldn't have to pass the user object for each operation).

@@typealias thanks for explaining!

You want all of the design patterns in a single video? That might end up being a pretty long video! 🙂

@@typealias ofc not in single video. One design pattern per video is great

Haha, okay gotcha! I'll keep at it, then - only about 20 videos to go! 🙂 I actually might end up having to do a single round-up video for a few of the "leftover" patterns that wouldn't really warrant their own videos. Like - singleton wouldn't take too long to explain. And for some of the others, Kotlin doesn't add much. Anyway, thanks for clarifying!

@@typealias omfg this is my dream to see these videos! Thank you so much! Can't wait!

Well, adding another function would require us to revisit each of the state objects - I think that's what you're getting at. Even then, though, I would find it easier to manage the smaller, more focused functions that are grouped by state rather than large functions that are each trying to juggle different implementations for multiple states. (But if I'm misunderstanding your point, let me know!)

Ahhh, yes you're right! Thanks for catching that. Should be printing `it` instead. 😅

I also prefer typed parameters in lambda for other developer's sanity.

Explicitly writing the lambda parameters is always an option, of course. It all depends on the team's conventions, or in case of solo projects, the developer's preferences.

@@ArthurKhazbs Absolutely, you project your rules, but here we are educating people, it seems :) and when I see such in the code: `val editProfile: (String) -> Unit` - how am I supposed to understand what would be passed here? And in this case I see at least 2 solutions - either name it `(email: String) -> Unit` or use tiny type - `value class EmailAddress(val email: String)` - then its inferred in the type what will be passed.

Yeah! I almost never use semicolons... In this case, at a glance it looks like it might be part of the println() statement, so it'd be easy to miss what's happening!