Hullaballoonatic
04/10/2019, 6:02 PMMike
04/10/2019, 6:18 PMdrop(2)
? Actually, would it be drop(3)
? Another reason to avoid it. Is it 0-based? Is it inclusive or exclusive? drop(n)
is again unambiguous.
Again, more typing, but it’s already there, and doesn’t require parsing.
Same reason I’m opposed to introducing the ternary operator rather than just using if/else
on one line.
If you come from Java/Groovy, you have learned the ternary. If you didn’t, think back to the first time you saw it, and had to have it explained to you.
And at least in Java, ?
and :
don’t have any other meaning, whereas in Kotlin, they have other meanings depending on how they appear.Hullaballoonatic
04/10/2019, 6:23 PMif/else
is already inline
And as I alluded to, yes, foo[2..]
is the same as foo.drop(3)
but foo[..3]
is foo.take(4)
, but I imagine them being the same function, as opposed to two different functions. Does that make sense?ghedeon
04/10/2019, 6:41 PMdrop
or take
or whatever workaround name will be cleaner than [..k]
or [k..]
. Same reason why arrayOf()
will be always a sad bump in kotlin.gildor
04/10/2019, 11:41 PMHullaballoonatic
04/10/2019, 11:47 PMIntArray
and Array<Int>
gildor
04/10/2019, 11:48 PMHullaballoonatic
04/10/2019, 11:48 PMList<Int>
already cover the former properties?gildor
04/10/2019, 11:50 PMHullaballoonatic
04/10/2019, 11:51 PMArray<T>
only exists because of its existence in the jvm. We could easily get by with only List<Int>
and IntArray
, I believe.gildor
04/10/2019, 11:52 PMHullaballoonatic
04/10/2019, 11:53 PMIntArray
and Array<Int>
is certainly a poignant sour spot.gildor
04/10/2019, 11:54 PMHullaballoonatic
04/10/2019, 11:54 PMgildor
04/10/2019, 11:54 PMHullaballoonatic
04/10/2019, 11:55 PMgildor
04/10/2019, 11:55 PMHullaballoonatic
04/10/2019, 11:55 PMgildor
04/10/2019, 11:55 PMHullaballoonatic
04/10/2019, 11:56 PMgildor
04/10/2019, 11:56 PMHullaballoonatic
04/10/2019, 11:57 PMIntArray
or a List<Int>
, yeah?gildor
04/10/2019, 11:57 PMHullaballoonatic
04/10/2019, 11:58 PMgildor
04/10/2019, 11:58 PMHullaballoonatic
04/10/2019, 11:59 PMList<Int>
, MutableList<Int>
, and ImmutableList<Int>
could cover all the bases, meaning both Array<Int>
and IntArray
could kick the bucketgildor
04/11/2019, 12:16 AMHullaballoonatic
04/11/2019, 12:17 AMgildor
04/11/2019, 12:22 AMin
operator
Like:
if (x in [2,5,7])
Hullaballoonatic
04/11/2019, 12:24 AMx in {2,5,7}
gildor
04/11/2019, 12:25 AMHullaballoonatic
04/11/2019, 12:25 AM[]
be used for list literals and {}
used for collection or set literals? Since we don't have object literals.to
infixgildor
04/11/2019, 12:27 AMto
literalHullaballoonatic
04/11/2019, 12:27 AMgildor
04/11/2019, 12:28 AMHullaballoonatic
04/11/2019, 12:29 AMto
isn't any clearer than :
gildor
04/11/2019, 12:30 AMto
is not even part of the language or syntax, so it much more simpleHullaballoonatic
04/11/2019, 12:30 AMPair.invoke()
gildor
04/11/2019, 12:31 AMHullaballoonatic
04/11/2019, 12:31 AMas
operator, but iirc that's a feature in a few languages and can make code vague in readinggildor
04/11/2019, 12:32 AMHullaballoonatic
04/11/2019, 12:32 AMfun bar(baz: (Int) -> Any) {
// stuff
}
fun foo(foz: Int): Any {
// stuff
}
val bafo = bar(foo)
as opposed to the current
val bafo = bar({foo(it)})
gildor
04/11/2019, 12:39 AMbar(::foo)
Hullaballoonatic
04/11/2019, 3:51 AM::
syntax for a couple years. forgot it existed. still don't know what it doesghedeon
04/11/2019, 5:21 AMArray<Int>
and IntArray
is important but in perspective, Declarative is superior to Imperative. We need to offload accidental complexity that was introduced over the years. WHAT
is superior to HOW
. Foreach is better than for loop, because you don't see how it's implemented. That's why listOf
tells you nothing about its implementation (HOW), because, frankly, nobody cares. In ideal world we don't want to care about IntArray
as well. One day.... 😏gildor
04/11/2019, 5:35 AMIn ideal worldThere is no ideal world, and Kotlin is not about ideal, it’s to be practical and pragmatic
ghedeon
04/11/2019, 6:20 AMgildor
04/11/2019, 6:33 AMnot as efficient with the current collections as you’d do it imperativelyWhat do you mean?
ghedeon
04/11/2019, 7:50 AMpartition, window, plus, zip, etc
in kotlin you'll get a significant hit on performance. So, it's kind of there, begging to be used, then you check the implementation, see a lot of copying and most probably end up implement it in old imperative way, with mutable state. Idk, as an exercise, functional Pascal Triangle in kotlin https://pl.kotl.in/HkTog_ht4. That's a lot of allocations there 😒imple_smile: . Supposedly, an advanced low level toolchain will be able to optimize it in a way, that you don't have to be concerned of your operator implementation and just write the code that is as close to formal specification as possible.gildor
04/11/2019, 8:53 AMMike
04/11/2019, 10:36 AMHullaballoonatic
04/11/2019, 7:36 PM[1,2,3]
for lists. Arrays to be removed from Kotlin. [1 to 1, 2 to 1]
or [1:1, 2:1]
for maps and {1,2,3}
for sets/collections.kotlin 1.3 introduced then for annotations and intellij now recommends then.is
then
something added in 1.3? I'm confused. Not seeing it in google searches
Also, I agree that java is getting a lot nicer to use, but it still lacks any feature that Kotlin doesn't already have (except.... array literals). So maybe it'll get there, but it seems like such a long way off.Mike
04/11/2019, 8:30 PMgildor
04/11/2019, 11:04 PM