Uh, `Number` doesn't enforce the presence of `unar...
# getting-started
c
Uh,
Number
doesn't enforce the presence of
unaryMinus
. Is there a subtype for "`Number` instances that also have a
unaryMinus
?" I have a DSL which has a
+=
operator, I thought I'd provide a
-=
operator for convenience, but I would need to negate the value for that
s
Huh, that's interesting. I don't think there's a subtype for that... I initially thought it was because of unsigned number types, but those don't inherit from
Number
(nor do they have their own interface, surprisingly).
c
I think it's to allow you to create your own impl of
Number
for complex numbers or other weird cases
s
Yeah, potentially Unsure what's your use-case, but adding overloads for each of the built-in
Number
types may be an option.
r
Number
doesn't enforce the presence of any operator, so I would whatever you did for the
+=
operator is exactly the same as what you would do for the
-=
operator, correct?
s
(this is one of those situations that something like Rust's trait system would've helped with)
r
> ...allow you to create your own impl of
Number
for complex numbers... I'm not sure that's such a useful argument, since the existing functions on
Number
(e.g.
toInt
) don't really make sense for complex numbers either.
e
Number
doesn't enforce the presence of
unaryMinus
it doesn't enforce the presence of anything except conversion to primitives.
AtomicInteger
is a
Number
.
I think it's to allow you to create your own impl of
Number
for complex numbers or other weird cases
I don't agree. various parts of the Java only handle the specific built-in numeric types (e.g. Format), but there was no way to enforce sealed classes in Java originally, and that's carried into Kotlin for compatibility. it's not a useful class to extend