Am 15.02.2012 17:37, schrieb Sergiu Ivanov:
This is how I envision the structure of a module that would approach
the problems I described. It should include a Python class to
represent an abstract category (call it Category), another one for an
object (CategoryObject) of the category and another one for a morphism
(CategoryMorphism). Category must expose a method to test whether a
CategoryObject is contained in it; likewise for CategoryMorphism.
CategoryObject must have a name. CategoryMorphism must have a name
and references to its domain and codomain.
That's reasonable.
> In the cases of concrete
categories the user is expected to derive their own classes which
would define the corresponding structure.
From my perspective as an OO architect at work, I have this advice to give:
Avoid putting any logic into the Category class then.
Otherwise, users will try to get creative by overriding functions from
Category, and break Category or even SymPy as a whole because they do
not have the experience nor discipline to write overrides that honor the
contracts of the functions in the superclass.
(The problem gets worse if the contracts are not fully spelled out. And
they usually aren't because a lot of contract clauses are self-evident
for programmers, but maybe not so self-evident for mathematicians or
physicists.)
--
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.
