Many of the Math builtin functions are a bit convoluted for example:
pub(crate) fn abs(_: &Value, args: &[Value], _: &mut Interpreter) -> ResultValue {
Ok(Value::from(if args.is_empty() {
f64::NAN
} else {
f64::from(args.get(0).expect("Could not get argument")).abs()
}))
}
This is also inefficient because we check if there is an argument and then another check is done when we call .expect().
A better way of doing this would be to use .map_or which would simplify the code a lot:
pub(crate) fn abs(_: &Value, args: &[Value], _: &mut Interpreter) -> ResultValue {
Ok(args.get(0).map_or(f64::NAN, |x| f64::from(x).abs()).into())
}
I鈥檒l take this
I鈥檒l take this
Sure!
@HalidOdat There are still some methods that can be cleaned up in this issue. I just did the ones that were quick and easy.
@HalidOdat There are still some methods that can be cleaned up in this issue. I just did the ones that were quick and easy.
In that case, I'll reopen the issue :)
In that case, we might benefit from mapping which methods still need refactoring:
There are a couple of these functions that are not yet implemented. Are there separate issues tracking the implementation of those functions?
There are a couple of these functions that are not yet implemented. Are there separate issues tracking the implementation of those functions?
we don't have an issue for tracking the unimplemented ones. I'll create it :)
Edit: #524
Most helpful comment
In that case, we might benefit from mapping which methods still need refactoring: