Channels
#stdlib
- i
ilya.gorbunov
03/09/2016, 3:29 PMfrom the same docsThis interface imposes a total ordering on the objects of each class that implements it
- v
voddan
03/09/2016, 3:29 PMInterface - v
voddan
03/09/2016, 3:29 PMnot operator - i
ilya.gorbunov
03/09/2016, 3:31 PMIf you want to sort a collection, it's better to create a comparator, because extension operator overloads would have no effect on the sort order. - v
voddan
03/09/2016, 3:34 PMthat's right. I am saying that it is OK to brake the contract for
while keeping the contract ofcompareTo
, since it does not let anybody to use it in the wrong way (ei sorting)Comparable - v
voddan
03/09/2016, 3:35 PMI am not a Java guru, that's why I ask here. Not for the sake of asking. In case it looks like I am playing with words - i
ilya.gorbunov
03/09/2016, 3:41 PMI believe it could confuse a reader who assumes that
and related operators usually come from implementation ofcompareTo
— he could make wrong conclusions about the contract. If I ultimately need to have such operator overloads I would scope them as narrow as possible, for example with member-extensions:ComparableCopy code
Here a reader would have more chances to notice that it's not usualobject MyPartialOrderComparator: Comparator<Class<*>> { override fun compare(p0: Class<*>?, p1: Class<*>?): Int = TODO() operator fun Class<*>.compareTo(other: Class<*>): Int = compare(this, other) } fun partialOrderUsage(c1: Class<*>, c2: Class<*>): Boolean { with (MyPartialOrderComparator) { return (c1 < c2) || (c1 > c2) } }
andgreater than
operators and that theless than
could be somehow involved in semantics of comparisons.MyPartialOrderComparator - v
voddan
03/09/2016, 3:47 PMok, makes sense - v
voddan
03/09/2016, 3:47 PMnot for stdlib in that case - v
voddan
03/09/2016, 3:48 PMsometimes it is very tempting to introduce a DSL for something java-ugly in stdlib 😄 - m
mplatvoet
03/09/2016, 6:41 PMJust wondering, is the standard library supposed to be the same for the js backend? - m
mplatvoet
03/09/2016, 6:41 PMor is that a completely different library - m
mplatvoet
03/09/2016, 6:41 PM? - i
ilya.gorbunov
03/09/2016, 6:49 PMIt's a different library, however most of code is shared with the kotlin stdlib from jvm. - b
bashor
03/09/2016, 6:51 PM@mplatvoet: stdlib API can be divided to platform agnostic and platform specific parts. The implementation of API can be platform agnostic or platform specific too. - m
mplatvoet
03/09/2016, 6:53 PMokay, thanks for those answers. It’s a difficult tradeoff between making the stdlib confortable for Java devs and suitable for a JS backend. - m
mplatvoet
03/09/2016, 6:54 PMI wonder what the target audience will be for Kotlin with the JS backend - b
bashor
03/09/2016, 6:58 PMI think mostly devs who already (or going to) use Kotlin at backend - b
bashor
03/09/2016, 6:58 PMBTW we rewrite try.kotl.in frontend to Kotlin - m
mplatvoet
03/09/2016, 7:01 PMcool, open sourced? because I think try.kotl.in has also a lot of potential for workshops, would be great if it could be (easily) modified with custom training courses. - b
bashor
03/09/2016, 7:01 PM - m
mplatvoet
03/09/2016, 7:02 PMgreat, then I will stop cluttering the channel now 😉 - j
jw
03/10/2016, 8:20 PMwhat do we think about a
function on Map that uses a provided function on collisions?merge👍 2 - j
jw
03/10/2016, 8:20 PMor is this built in but named something more eclectic that I just can't find? - j
jw
03/10/2016, 8:21 PMCopy codefun <K, V> Map<K, V> merge(other: Map<K, V>, combineFunc: (V, V) -> V) = ... - j
jw
03/10/2016, 8:22 PMor maybe an additional type param for the resulting type of the map? - c
cedric
03/10/2016, 8:23 PMMight as well - j
jw
03/10/2016, 8:23 PMi'm thinking too much out loud - j
jw
03/10/2016, 8:23 PMlet me try some things first - c
cedric
03/10/2016, 8:23 PMIf you have a third type, you also need a third parameter
)map: (K) -> T