`toRadians` and `toDegrees`. Both are present in `...
# stdlib
e
toRadians
and
toDegrees
. Both are present in
java.lang.Math
but for MP it's a problem
k
I was about to comment that
toRadians
and
toDegrees
would work very nicely with value classes, but then realised that these require
@JvmInline
so are not usable with multiplatform 🤦‍♂️
e
value classes work on all platforms, it's only JVM that requires the annotation to disambiguate from future Valhalla value types
k
Ah, that's good! I only use Kotlin on the JVM, so wasn't aware of that!
i
I prototyped once such value classes and found the result not satisfying. If we provide them only to do the conversions, it's not much better than providing just these functions, and if we specialize trigonometric functions to accept these types, it will require a lot of overloads, and in some cases - overloading by return type which is not possible. For example, what would be the return type of
asin(...)
(arc sine) function, if there are several types for angular units?
k
That makes sense. Perhaps we can keep treating radians as the "natural" unit of angle, and require special treatment for degrees:
Copy code
val rightAngle = 90.deg                       // property deg is defined on Double (or Number)
val y: Double = sin(rightAngle.toRadians())   // sin is only defined for radians
val theta: Radians = asin(y)                  // asin(Double) returns Radians
val theta2 = theta.toDegrees()                // toDegrees() is defined on Radians
e
a vaguely related thought… do we really need to represent angles outside of `-*π..<π`/`-*180°..<180°`? (or maybe some small multiple of that) if not, given the same storage size, a fixed-point representation covering that range could have more useful precision than the subset of floating point numbers within that range
k
That's an interesting thought, but there are real-world use cases in engineering, e.g. "this bolt should be turned 720° clockwise", or you might want to convert rpm to radians per second. Still, the increased precision you talk about sounds appealing.
m
they could always be 2 different classes. One being angle, the other rotation
and then define an
operator fun Angle.plus(rotation: Rotation): Angle
etc.
k
I like that! It reminds me of Instant and Duration as being analogous. Also, we can define the properties
Double.deg
and
Double.rad
so they both return
Angle
, and
Angle.toRadians(): Double
(trivially returns the value) and
Angle.toDegrees(): Double
(converts value held in radians to degrees).
e
overloading by return type which is not possible
cant
@JvmName
helps with that?
e
no. the JVM doesn't care whether they have the same name or not, it's a language limitation
e
I wish Kotlin could transparently mangle the names underneath for the JVM but offer the same names (taking into account different return type, inline classes as well) to the developer
e
it doesn't matter if it's mangled or not, the JVM does not reject multiple methods with the same name and signature differing in return type only
it's a language issue: Kotlin can't handle that (it'll definitely have interactions with type resolution). also even adding that, it'll be completely unusable from Java
e
Except that there are already corner features unusable from Java, with
JvmNames
the dev could specify the name to be used underneath (and visible from Java)
e
sure, but that's unrelated to the fact that Kotlin can't handle overloads by return type only, on JVM or any platform
356 Views