Additionally, operations are provided that can take any scala.math.Numeric type as long as an implicit of that
type is available at call time.
This functionality assumes that the type arguments are the same as it relies on scala.math.Numeric. When the types
are the same, everything works seamlessly.
When the types for the function arguments don't line up, we get a compile time error.
scala> Some(1) + Some(1.5)
<console>:12: error: type mismatch;
found : Double(1.5)
required: IntSome(1) + Some(1.5)
^
Because inline operations require the use of implicit classes, inline syntax will incur an object creation
overhead that using OptMathOps will not.
import com.eharmony.aloha.feature.OptionMath.Syntax._
import com.eharmony.aloha.feature.OptionMath.OptMathOps
val a = Option(1.5)
val b = Option(0.5)
val c = a / b // Additional object creation involved (slower, prettier)val d = OptMathOps.div(a, b) // Less object creation involved (faster, uglier)
assert(c == d)
Notice that the usual order of operations in the same.
Provides basic inline unary and binary mathematical operators for options of primitive types including.
- Option[Byte] - Option[Short] - Option[Int] - Option[Long] - Option[Float] - Option[Double]
Additionally, operations are provided that can take any scala.math.Numeric type as long as an implicit of that type is available at call time.
This functionality assumes that the type arguments are the same as it relies on scala.math.Numeric. When the types are the same, everything works seamlessly.
When the types for the function arguments don't line up, we get a compile time error.
Because inline operations require the use of implicit classes, inline syntax will incur an object creation overhead that using OptMathOps will not.
Notice that the usual order of operations in the same.