OpenRanges are something I made myself as well. Sometimes you want to check if a value lies in multiple ranges like in a when. You cant check both "is smaller than 3" and "lies between 3 and 4" and "is bigger than 4" nicely. By defining null..3, 3..4, 4..null to all exist as ranges, you can more easily check. We also use it a lot because we're dealing with periods in dates and we want to check wether or not a date is "active", if a period has no defined enddate yet (null), this means that the check becomes trivial: date in start..end (where end is nullable)
Oh nice! Really useful, would be nice indeed. Here again Guava has this. I gotta say your use case is really good, this would be quite ugly otherwise. Thanks for your comment and elaborating 💪🏻
Why would these be in the standard library? They add something to your specific usecases, and they are easy enough to write yourself. I would say the Triple one is ambiguous to creating a Pair, as well as triples shouldnt be overly used as they are not really readable, Triple, which one is which? So i get it that they want to discourage using it. Also, why pass the boolean argument in whenTrue and whenFalse? Also, are you sure it brings more readability? I also have a bunch of the doIfTrue, or applyIf, but never found the silver bullet there.
You're having good points. I agree with you that `.whenTrue {}` is not required to have, just nice. But I mean that's why there's a ranking to them and it's just my personal ones. Maybe below the Top 5, they are not general enough. However, specifically the Top 3, I think would fit well into the standard library. But anyhow, as I'm saying in the second part of the video, it's not a big deal that all of those are not there as one can easily add them. If they are easy to write or not is a good point but many of the built-in ones are also one-liners. My point was more that it's nice to have them available, but it's not the end of the world that they aren't - on paper they couldn't ship any standard library and we could write all of it out ourselves.
That's why they gave concept of extension. You can add how much you want based on your use case. I feel they kept it simple and covered all required extension functions in standard library.
Yeah exactly, that's what I'm pointing out in the end as well. I do agree that the one in the lower ranks on my list are probably not good candidates to make it into the standard library as they are not general enough. Do you have some that you use a lot that you wrote for yourself?
@@TheSelfTaughtSoftwareEngineer I use extension functions mostly on Android framework apis as I come from mobile development background than pure kotlin apis.
Right, I did notice that this is a very common use case for extension functions, I don't do much Android development but that's a great use case to hide some complexity of the more cumbersome Android APIs. I saw a lot of people extending stuff onto `View` or the `Lifecycle` 👌🏻
Nice. I liked this. Thanks, man!
Happy to hear, thanks 🤗
OpenRanges are something I made myself as well.
Sometimes you want to check if a value lies in multiple ranges like in a when. You cant check both "is smaller than 3" and "lies between 3 and 4" and "is bigger than 4" nicely.
By defining null..3, 3..4, 4..null to all exist as ranges, you can more easily check.
We also use it a lot because we're dealing with periods in dates and we want to check wether or not a date is "active", if a period has no defined enddate yet (null), this means that the check becomes trivial: date in start..end (where end is nullable)
Oh nice! Really useful, would be nice indeed. Here again Guava has this.
I gotta say your use case is really good, this would be quite ugly otherwise. Thanks for your comment and elaborating 💪🏻
Very cool extension functions. Thanks for sharing!
Why would these be in the standard library? They add something to your specific usecases, and they are easy enough to write yourself. I would say the Triple one is ambiguous to creating a Pair, as well as triples shouldnt be overly used as they are not really readable, Triple, which one is which? So i get it that they want to discourage using it.
Also, why pass the boolean argument in whenTrue and whenFalse? Also, are you sure it brings more readability? I also have a bunch of the doIfTrue, or applyIf, but never found the silver bullet there.
You're having good points. I agree with you that `.whenTrue {}` is not required to have, just nice. But I mean that's why there's a ranking to them and it's just my personal ones. Maybe below the Top 5, they are not general enough. However, specifically the Top 3, I think would fit well into the standard library. But anyhow, as I'm saying in the second part of the video, it's not a big deal that all of those are not there as one can easily add them. If they are easy to write or not is a good point but many of the built-in ones are also one-liners. My point was more that it's nice to have them available, but it's not the end of the world that they aren't - on paper they couldn't ship any standard library and we could write all of it out ourselves.
Can you make the code publicly available?
Sorry that this took so long! Here you go :)
gist.github.com/loehnertz/3b118d66fc349f47993f8e6b9ffccf7a
Let me know if you got any other questions!
@@TheSelfTaughtSoftwareEngineer thank you
That's why they gave concept of extension.
You can add how much you want based on your use case.
I feel they kept it simple and covered all required extension functions in standard library.
Yeah exactly, that's what I'm pointing out in the end as well.
I do agree that the one in the lower ranks on my list are probably not good candidates to make it into the standard library as they are not general enough.
Do you have some that you use a lot that you wrote for yourself?
@@TheSelfTaughtSoftwareEngineer
I use extension functions mostly on Android framework apis as I come from mobile development background than pure kotlin apis.
Right, I did notice that this is a very common use case for extension functions, I don't do much Android development but that's a great use case to hide some complexity of the more cumbersome Android APIs. I saw a lot of people extending stuff onto `View` or the `Lifecycle` 👌🏻