https://kotlinlang.org logo
Join Slack
Powered by
`Number` changed from Abstract Class to Interface,...
# stdlib
h
Number
changed from Abstract Class to Interface, given it is purely composed of abstract methods.
👍 2
Probably can't ever occur due to compatibility reasons, which is a real shame. I'd love to be able to extend 
Number
in interfaces
k
One solution is to not use 
Number
, ever. It's a near useless class, none of the functions it requires are guarateed to do something meaningful on all numbers.
👍 1
h
yeah, i really wish all the Number subclasses in stdlib shared an interface that included the mathematical operators (on only their class and producing their class) as well as Comparable
k
That's great util someone wants to implement complex numbers, which don't have a well defined order.
The nice solution would be to go the rust way, define an interface for every operation including comparison separately, but to get that working you need a self type which we don't have.
👍 1
👆 2
h
yeah, i'm so rust-curious
it's another language i think i have the potential of loving
➕ 1
my ill-informed idea of it is that it is to C what Kotlin is to Java
k
In that it's a very cleaned-up version, sure. But Kotlin is trivial to learn if you know Java, C -> Rust is very hard.
h
Well I'm not exactly the most accomplished programmer in C to begin with, so....
k
Well any GC language to Rust is even more difficult, it really is a different way of thinking
z
There’s a proposal being discussed for typeclasses in kotlin, which could open up some interesting possibilities for this sort of thing: https://github.com/Kotlin/KEEP/pull/87
👍 1
m
If we had a chance to redesign Java's Number, I'd like also 
Boolean
to be a valid 
Number
.
k
I'm curious, what's the use case for that?
m
I don't remember this ¯\_(ツ)_/¯
h
@karelpeeters i'd use it like this from time to time 
print(bool * bar)
if the bool is false you get 0 otherwise you get the bar thus working kind of like 
?
k
If only there was an existing operator on booleans that did exactly that...
Ah you mean if 
bar
isn't a boolean? Yikes simple smile
s
too bad kotlin is forced to follow java's mistakes... kotlin native could have been something huge
instead rust will steal the show
k
They're not even remotely similar.
s
they are
➕ 1
k
GC isn't that important of a difference, right?
s
GC is pluggeable, you can have what ever thing you want
h
I should note that I think 
Number
would be best if implemented as so:
Copy code
interface Number<N: Number<N>> : Comparable<Number<*>> {
    operator fun plus(other: N): N
    operator fun minus(other: N): N

    operator fun unaryMinus(): N
    operator fun unaryPlus(): N = this

    operator fun times(other: N): N
    operator fun div(other: N): N
}
I'd personally also toss in
Copy code
infix fun pow(other: N): N
infix fun root(other: N): N
val inverse: N
But that's probably asking too much...
k
That's great until 
-
doesn't work (natural numbers) root isn't defined (integers), division isn't defined (quaternions), ... You really do need separate interfaces.
h
fuck. i only know quaternions by name and reputation. at the very least you could let Number be Comparable
🙂 1
k
That fails even earlier at complex numbers.
h
well then, at the even leaster... I see no reason it couldn't be an interface
m
Rust has 
Cmp
and 
PartialCmp
, 
Ord
and 
PartialOrd
, to handle NaNs. Same may be applicable for computing roots, doing division, etc
5 Views
Open in Slack
PreviousNext
Powered by