Hello Travis, So the proposed change isn't really that big after all, just a >> renaming and the addition of one level of nesting. >> >> class MyCategory(Cagetory_singleton): >> class Object: >> ... >> class Element: >> ... >> >> I'm against this because that means there is a special attribute of > the Object that the code must handle differently because it cannot simply > allow it to be overwritten by (abstract) parent classes. >
What do you mean exactly? Which code must handle Element differently, and what does overwriting Element mean? There is already code that handles C.ElementMethods and Parent.Element specially for constructing P.element_class for parent instances P. What I am proposing is that in concrete categories C (subcategories of Sets), C.Object should be an instance of Parent, and C.ElementMethods should be merged into C.Object.Element. The latter should then be used (for C.Object itself and for Object classes of supercategories) to construct P.element_class, in a similar way as C.ElementMethods and Parent.Element are used now. In terms of functionality, C.Object and C.Object.Element would be the place to _logically_ put the code of the existing (and partially deprecated) static inheritance hierarchy of all the various types of rings and the corresponding *Element classes. The _actual_ placement of the code for these classes could by either inline (as with C.ElementMethods) or by setting C.Object = MyParent and MyParent.Element = MyElement, where MyParent and MyElement can be defined in separate files. For the concrete example of Euclidean domains that has been discussed, the proposal would be to - move EuclideanDomain to EuclideanDomains.Object - move EuclideanDomainElement to EuclideanDomains.Object.Element - merge EuclideanDomains.ElementMethods into EuclideanDomains.Object.Element - if a parent P is constructed and determined to be a Euclidean domain: - - make P dynamically inherit from EuclideanDomains.Object, and from Object classes of supercategories of EuclideanDomains - - make P.element_class dynamically inherit from EuclideanDomains.Object.Element and from Object.Element classes of supercategories of EuclideanDomains. The advantages would be: (1) the relation Category -> Parent -> Element is better respected by not letting categories prescribe the behaviour of elements directly, but only via parents; (2) at the moment there seems to be some confusion about what should be in ElementMethods and what should be in Element classes. For myself, this confusion is largely caused by the fact that ElementMethods are attached to categories instead of parent classes. In the above picture, it is clearer where methods belong. Among the various Element classes, some of them might be Cython classes, but one would have to be careful in saying which ones are allowed to be (because of multiple inheritance). I assume more of the inheritance would have to be specified by hand, but maybe less so than in the existing *Element hierarchy. All of this is probably not so different from what the experts mean by "moving something to the category framework", and many of my thoughts about this might just be repeating other people's ideas of how to do this. Again, the thing I want to stress is that I think it should be done in a way that clearly reflects the Category -> Parent -> Element relation. In fact, thinking of Volker's remark that the category framework is not necessarily about mathematical categories, I am tempted to think of it as the "category-parent-element framework" instead. Is is also not clear that inheritance in categories and the parent classes > could not come into conflict. Basically I'm worried about a diamond-type > problem, suppose we have the categories C1 and C2 and parents P1 and P2 > with the following inheritance structure: > > C1.E <- C2.E > ^ ^ > | | > P1.E <- P2.E > > where X.E denotes the element class. In particular, P1.E gets methods from > C1.E, which are then inherited by P2.E and could override C2 > implementations from C1. With the current way of having it be > ElementMethods, there's no confusion where the methods are coming from. > Maybe I'm just being somewhat paranoid about things (or more likely missing > or not understanding something)? > That would not be an issue in my proposal, because it would move all the element classes to the parents, so the Ci.E would not exist anymore. Where the categories come in is when the subcategory relation is used to _construct_ the Pi.element_class, as in the above example for Euclidean domains. 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.
