Wearing my software architect hat:
Am 09.03.2012 01:51, schrieb Aaron Meurer:
So you want to separate the canonicalizers from both the objects and
the containers? It seems to me that it would be best to just put them
in the objects themselves, probably just using the Python double
dispatch system, but this is an interesting idea too.
Multiple dispatch or multiple inheritance?
Multiple dispatch (i.e. selecting the function to be executed based on
the type of more than one parameter) makes extending the system via
subclasses unmodular: people cannot extend independently, they must
coordinate.
Assuming that X' is a subclass of some class X,
if we have a function f(A,B),
and some person writes A' and defines f(A',B),
and somebody else writes B' and defines f(A,B'),
and a third person wants to use both A' and B', and calls f(A',B'), that
call is ambiguous, it could go to the A' or the B' variant of f.
In most likelihood, both are wrong since the A' and the B' variants of f
were written because the new subclasses needed new code in f.
So if somebody wants to combine A' and B', he needs to "fill the matrix"
with a new f(A',B').
It would be possible to do this inside SymPy. Just document which
functions are using multiple dispatch, and warn potential subclass
authors that overriding these functions requires coordination with
anybody writing a subclass on another parameter.
Multiple inheritance as done in Python is unsound in the presence of
diamond inheritance.
I have an essay on the topic; see
http://durchholz.org/essays/object-orientation/diamond-inheritance/
IMNSHO, Python's C3 MRO is better than the original mechanism but still
hopelessly inadequate.
In general, this is not a big problem. However, SymPy would be
particularly vulnerable, since it is dealing with a hierarchy of
mathematical concepts, with abundant diamond structures (actually, the
essay uses hypothetical Group and Monoid classes to explain the
difficulties).
> Would that make it more or less extensible?
More extensible, until the mechanisms are in widespread use, then it
will start becoming less extensible.
My advice would be to stick with
- single dispatch
- single inheritance
- finding ways to structure the logic so that these two are enough
- where that does not work (and we will have that), program some
explicit mechanism for resolving what needs to be done in what case.
I hope this has shed some light on the issues.
I'm aware that this were some pretty strong statements on a sometimes
controversial topic. Feel free to ask questions, or to challenge
assumptions and conclusions.
Regards,
Jo
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
