Hi Volker, On 2013-09-14, Volker Braun <vbraun.n...@gmail.com> wrote: >> I am also not so happy with this formulation. It is similar to Python >> inheritence, since it actually *provides* inheritance. > > > No it doesn't, and not having this point stressed confused me for a long > time.
Yes, it does. > Inheritance always piles on stuff: Subclasses are their base classes > plus more. And that is precisely what categories don't give you: You can > stick the base class into one category C1 and the derived class in a > different category C2, and the derived class will not know the slightest > about C1. I am not totally sure what your example looks like. What do you mean by "stick the base class into one category C1"? Do you mean "create an instance of the base class, the instance being an object of C1"? Or do you mean "provide the base class as C1.ParentMethods"? In any case, if you have an instance P of the base class and and use the category C1==P.category(), then P will inherit both from the base class and from C1.parent_class, and in particular it will inherit from C2.parent_class for all super-categories of C1. In this sense I stated that it provides inheritance. Actually, if the base class is a Python class, then the category framework provides a (dynamic) Python class, and all what I stated above is just *the same as* inheritance in Python. Hence, you could mimmick the category framework by statically implementing the Python classes that the category framework creates dynamically. But why should you do so, since the category framework does this work for you? > Coming back to the original question, should something be implemented as > method of RingElement or as Rings.ElementMethod? Often, both is feasible. I would actually *recommend* to do both at the same time in *most* cases: Work on top of the base classes in sage.structure, and then initialise the category framework for your parent and element. > In principle, we could do away with RingElement: All elements just inherit > from Element and use categories to get their module/ring operations. But > that would also raise the barrier of entry for Sage significantly, as it is > much more difficult to write a first implementation of some ring structure > that already correctly uses the category machinery. I am not so sure. IIRC, some (most?) of the algebraic base classes in sage.structure are abstract base classes, hence, can not be instantiated. So, in both approaches, it requires some effort to actually create a working example. > Also, you lose Cython > type checking since you can only check for Cython classes. What?? Python can check types as well (isinstance). And actually the category framework uses (to some extent) type checking of C.parent_class in order to test whether a category C is subcategory of another category D. > To summarize, the rule should be: attach methods to the Element hierarchy > if there is a "perfect fit". If not (that is, if your method doesn't make > sense for each and every ring) then put it in the appropriate > SpecialRings.ElementMethod. Better do both, generally. Best regards, Simon -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
