Hey Peter, 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. >
When constructing the parent object, the category can't simply use inheritance, it must take special consideration of the attribute Element in *both* the category's Object and the original Parent class instead of just one. I'm worried about how this might affect inheritance and assignment of element methods given by the category. In particular, suppose C is a supercategory of D, and D is the category of P. Suppose a method foo() is implemented in C.Object.Element and you want to call that from P, either directly because P does not implement it or via a super call. There's more indirection that has to go on that seems like unnecessary complication to me. 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. > From a programming perspective, using C.Object.Element does not describe what occurs. Element/ParentMethods is self-documenting, and requires far less explanation to a new user IMO. I'm also in favor of less nesting and avoiding the use of the loaded word "Object". However I do agree that most (all) of the *Element classes should be moved into categories. 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; > Doesn't the category you're in dictate what operations your elements can do? For example, if I know x is an element of a parent in Fields, I know I can invert x. So doesn't that imply that it makes more mathematical sense to put Element methods in the category rather than the object? > (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. > It doesn't seem like anyone is confused about this, but maybe with what should actually be a generic method and/or trying to mesh the older Sage parent/element hierarchy with the newer category framework. 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. > I don't believe this is an issue since the constructed element_class is a dynamic python class and currently all categories are python classes (I think they have to be...). > > 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. > Actually I've answered my own fears; there's no ambiguity. You're correct that this would not be in your proposal (although I should have stated C1.Object.E), but not as to why. It's because P1 does not know about C1, the parent constructed of P1 in C1 is not P1 but a dynamically created subclass, so there's no arrow from P1 to C1 (nor does this occur in the current setup). However I'm still worried that things become muddled with the super categories as above. In summary, I think that making this change would make the category framework not as clean of an implementation (and IMO it's sometimes better to sacrifice mathematical or logical correctness/rigor for clean code). Best, Travis -- 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.
