I think one of the confusions is that the category framework has something
to do with mathematical categories. In fact, it doesn't. It happens to be a
framework that we use to model mathematical categories, but that is just
coincidentally so because Sage happens to be about mathematics.
The Sage categories are, at their core, syntactic sugar on object
composition. In object-oriented programming, there are two basic ways to
make more complicated objects from simpler ones. One is inheritance:
class Simple(object):
pass
class Derived(Simple):
pass
and the other is composition:
class Composed(object):
def __init__(self):
self.simple = Simple()
Sage categories, at the end of the day, just make certain methods of Simple
appear as methods of Composed.
Inheritance is more rigid than composition, you cannot (or should not in
Python) hide inherited methods. Inheritance is easier to understand, in
part because it is more rigid. Which one to use? The rule of thumb is to
use composition over inheritance if in doubt. That also implies to use
inheritance if it is clear that you are inheriting. So when is it clear
that inheritance is to be used? Basically, when you can use the derived
type whenever a base type is expected. E.g. square is not a subclass of a
mutable rectangle, but it is a subclass of an immutable rectangle. Hence,
is_unit() should probably be part of on RingElement unless we mean by
RingElement just an element with multiplication and addition (in which case
it is really badly named TM).
There may also be technical restrictions that force you to use composition,
e.g. if your programming language doesn't support multiple inheritance.
That isn't really an issue in Python, but it is in Cython. Though it
doesn't seem to be the problem in your case.
On Friday, September 13, 2013 8:23:21 PM UTC+1, Peter Bruin wrote:
>
> Hello,
>
> A discussion was just started at http://trac.sagemath.org/ticket/15192about
> the reason why categories in Sage have a class ElementMethods. In
> this ticket, Julian Rüth moved the method is_unit from RingElement to
> Rings().ElementMethods to fix a certain bug. I thought this wasn't the
> only possible fix and wondered why the latter existed in the first place.
> We thought it would be a good idea to move the discussion here.
>
> For now let me just quote myself out of context (see the ticket for
> context):
>
> Parents describe relations between elements; e.g. a ring is a set whose
> elements satisfy certain axioms. Categories are on a higher level; they
> describe relations between objects, and it shouldn't matter too much what
> the elements of these objects are, or even if the objects are sets at all.
>
> Whether an element is unit depends on relations satisfied *within* its
> parent, not on relations between the parent and *other* parents. In other
> words, the category its parent is in should not play any role. It is true
> that some categories (like the category of rings) *are* in a sense
> defined by relations between the *elements* of objects, but exploiting
> this to influence the behaviour of elements is confusing two different
> levels of abstraction, in my opinion.
>
> Hence, I don't see a good mathematical reason for putting methods in
> Ring.ElementMethods instead of RingElement. I can see why one would want
> a Category to have ObjectMethods (which are now called ParentMethods) and
> perhaps MorphismMethods (which only exist in a doctest). With
> ElementMethods, however, I somehow get the feeling that the authors of
> the category framework are aiming for world domination!
> (Last sentence is tongue-in-cheek, of course.)
>
> Can someone more familiar with the category framework motivate the reason
> for ElementMethods? Are there methods that cannot or should not be put in
> the relevant element classes (such as RingElement above)?
>
> Thanks,
>
> Peter
>
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" 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/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
