I have a class similar to the follwing:
class NumberCruncher<T: Number>(val v: T) {
fun crunch1(v2: T) = v + v2
fun crunch2(v2: Double) = v + v2
}
The compiler produces an error for each method, because the operator plus method is not declared for Number. How about declaring the operators as abstract methods?
I donāt know what was the reason to not include this in the first place, but please remember that Kotlin intentionally doesnāt support math operations for inconsistent number types. You canāt add numbers to numbers, but integers to integers, doubles to doubles, etc.
I see a lot of questions about this ā itās clearly a source of some confusion.
Part of the problem is that it seems like Number should be such a powerful abstraction. Write the code just once, and it can work for all numeric types! No need to force your choice of Int or Double on everyone (or write umpteen versions of the same code)!
Unfortunately, there are two major problems: one fundamental, one pragmatic.
The fundamental one is that of the result types. If you add, say, a Float and an Int, what type should the result be? Thereās no natural answer; whatever you choose, it may not be able to hold the result exactly. And the same problem recurs for all combinations of numeric types, and for most binary operations. (And it gets even harder once you bring in the unsigned types.)
And even if you somehow hard-code the results for all the primitive numeric types, donāt forget that thereās also BigInteger, and BigDecimal, and any other subclasses of Number that you write yourself or find in third-party librariesā¦
Of course, thatās not a problem for operations upon two numbers of the same type. (Or at least, no more of a problem than we already have.) But that would be a bit restrictive.
The pragmatic problem is that java.lang.Number (to which kotlin.Number is mapped) doesnāt support anything except for a few conversion methods. So itās not easy for Kotlin to add them. (Again, even if it added lots of extension methods, they wouldnāt be able to cope with new Number subclasses.)
This is all very unfortunate. If java.lang.Number had been designed a bit more imaginatively (e.g. with a type parameter giving the concrete type, and lots more abstract methods), then it could have been far more powerful. But I donāt think itās possible for Kotlin to retrofit any of that, so weāre pretty much stuck with it.
(Of course, if anyone has any bright ideas, Iād be interested to see them!)
Interesting take. Just thought Iād mention my suspicion that similar requests for Number might often violate LSP.
For example, people are often tempted to make a Square a sub-type of Rectangle and LSP shows that is incorrect (except when immutable).
Does anybody know of any arithmetic that could be added to Number without violating LSP? Maybe non-arithmetic additions to Number could make sense but Iām having trouble coming up with one example of a valid arithmetic method that would fit for Number without something else major being changed to the language (ex. Self-types).
You could technically do something like this:
import java.math.*
operator fun Number.plus(other: Number): Number = toBigDecimal().add(other.toBigDecimal())
fun Number.toBigDecimal(context: MathContext = MathContext.UNLIMITED) = BigDecimal(this.toString(), context)
fun main() {
println((0.1 as Number) + 0.2)
}
I think with the right conversion afterwards this might not violate LSP. However, maybe due to the unlimited precision used weāre technically not doing the same rounding errors that would happen automatically, but I think something like BigDecimal probably matches the developers intent more since I doubt? that anyone relies on rounding errors.
Ah yes! I guess the only caveat is itās assumed all implementations if Number can be parsed into a BigDecimal through their toString().
Maybe a better request for OP is to have a toBigDecimal() conversation added to number, or alternatively an unlimited precision number type be added to Kotlin
Edit: And of course the caveat that the return type for any common operation with a Number would result in that unlimited precision type.
That might just about work (though in a very wasteful way) for the built-in numeric classes. But it can never be a full solution, because anyone can write an implementation of Number, working in any way they like!
For example, suppose someone writes an implementation that stores numbers as arbitrary-precision floating-point fractions in base 3 (ternary). Neither a decimal type nor a binary type could store even the simplest ternary fraction exactly (1/3 = 0.1ā ā 0.33333333ā¦āā ā 0.01010101ā¦ā). And of course similar applies to an infinite number of other possible number bases.
So no, there can never be an āĆ¼berā numeric type that can act as a superset of all the others, even with unlimited precision.
(Thatās why a full-featured Number type would be so useful, of courseā¦)
Good point.
It has me considering what a Number type is in kotlin. and now Iād describe it as: āA number type is a type that can be converted (not perfectly) into an int, double, float, ā¦ etcā
I guess it youād need a number type that can be converted to perfectly from all others to make any sense of it.
Also, hereās the link to more discussion Kotlin Number class mystery - #8 by akurczak
I suspect this thread isnāt the last in the chain either ;D
The Number class has a number (haha) of issues, but not the least of which is, even most of the existing methods are hard to implement for all numbers you might want to implement. For instance, complex numbers are numbers too. How do I convert that to a double?
If you look at what some libraries which reimplemented big decimals (like apfloat) ended up doing, they had their real number class extend from the complex number class, because all real numbers are also complex numbers. Others (like jscience) tried to model abstract algebra and then built the numbers on top of that, so the hierarchy in there would be friendly for someone who knows the terminology of that area.
But yes I think on the whole self types would have been a good thing for Number to have and Iām not sure why they didnāt let it have them. Many of the operators for the existing classes could have just been generic methods had they thought it out. But thatās really a common theme with generics. Thereās a ton of Swing classes which should now be generic but still arenāt.