> 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. 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)? Note that RingElement, with its coercion-specialized __div__, _div_, > etc. would still be a concrete ancestor separate from the category > framework, mostly for technical reasons, but most of this concrete > element hierarchy could/should go away. +1 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 [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.
