Gotta love extension methods. The fact that joda t...

# announcements

[Czar]

Gotta love extension methods. The fact that joda time does not provide is(Before|After)OrEqual methods bugged me even though the workaround is very simple. With Kotlin this is solved 😄

fun AbstractPartial.isBeforeOrEqual(other: ReadablePartial): Boolean = !isAfter(other)
fun AbstractPartial.isAfterOrEqual(other: ReadablePartial): Boolean = !isBefore(other)

The problem with directly using something like !isAfter(other) is the exclamation mark, arguably it is harder to spot and read than readable name like isBeforeOrEqual(other).

[louiscad]

Would add inline since it's a simple method call

[Czar]

IntelliJ doesn't like that, this will probably be optimized by compiler or JIT anyways, so no reason to have a redundant keyword there.

[louiscad]

@file:Suppress("NOTHING_TO_INLINE") to the rescue! Note that some "JVM"s don't have JIT. Examples are Android 5.0, 5.1 and 6.0. Android 7.0 and 8.0 have only a partial JIT

[Czar]

Yeah, our >1million java/kotlin code enterprise solution will never ever run on "some JVM" it is intended for big-ass servers with full fledged JVM 🙂

[Czar]

By the way later droids have AOT+JIT, which is kinda awesome 🙂

[louiscad]

Yep, but I doubt Android's 7.0+ JIT takes time to optimize such things. I guess it focuses to make the thing runnable ASAP so you wait a minimum amount of time

[Czar]

We're playing guessing game here. Let's not. I trust JetBrains enough to follow its advice on Kotlin 🙂 They suggest to remove inline here, so I happily oblige without suppressing stuff, disabling inspections, etc.

[dave08]

Why not just override operator <, etc...? 😉

[Czar]

Because:
1) mostly knee-jerk reaction to avoid operator overloading
2) readability, I always forget which date is less or more, before after is much more intuitive for dates
3) keeping the code base homogeneous, isBefore and isAfter are already used all over >1m loc code base which is mostly java with new stuff written in Kotlin.