Yet another alternative approach:
Instead of defining *Add* and *Mul* as dependent on a parametric type
associated with the properties of the expression, just do the opposite.
Examples (Julia-like syntax, {T} is the parametric type, <: means
inheritance):
type Expr{T} <: Basic
type NonCommutativeExpr{T} <: Expr{T}
type InfinitiesExpr{T} <: Expr{T}
type MatrixExpr{T} <: Expr{T}
type NonCommutativeInfinitiesExpr{T} <: Expr{T} # or better use multiple
inheritance?
Now, their corresponding *Add*, *Mul*, *Pow* classes are given by
NonCommutativeExpr{Add}
NonCommutativeExpr{Mul}
MatrixExpr{Add} # instead of MatAdd
MatrixExpr{Mul} # instead of MatMul
and so on.
This has the advantage to require developers to subclass the expression
only once, while the corresponding *Add*, *Mul*, ... objects are
automatically created by parametric typing. There is no
covariance-invariance problem for the parametric type, because it is not
using the template, it's using the main type in the dispatch, so this is
compatible with lots of other programming languages.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
