Hi Peter, On 2013-09-17, Peter Bruin <pjbr...@gmail.com> wrote: > I think many of your questions are addressed in the thematic tutorial on >> categories and coercion. >> > > I did read that, but it didn't quite suffice to make everything clear for > me. Also, there were some occurrences like "TODO: example" that made me > wonder if there would really be a natural example.
I just checked: The string "TODO" or "todo" does not appear in the thematic tutorial coercion_and_categories.html (title: "How to implement new algebraic structures in Sage"). So, what have you been reading? > I think I get this now. The point where I start to wonder if something > more natural couldn't be done is where C.element_class comes in. The > reason this makes me scratch my head is that it seems to skip a step in the > ordering Element - Parent - Category. Given that one has both > P.element_class and C.element_class, isn't there a way of moving all > functionality of C.element_class to P.element_class? A priori, this should > be possible since P.element_class is a dynamic class. P.element_class has two bases, namely P.Element and P.category().element_class (in this order). And C.element_class is an abstract base class, i.e., it is not supposed to be instantiated. This is different from P.element_class, which is a class that is actually recommendet to be used for creating instances (namely: elements of P). In other words, all functionality of C.element_class is already moved to P.element_class: When you create an element of P, you are *only* using P.element_class, and C.element_class is just one base class. > What still seems to be missing for this is something like an attribute > called C.Object (for example) to provide a default class for objects in the > category C. > I am thinking of the construction parallel to what P.Element > does for elements of parents. It doesn't. P.Element is just one base of P.element_class. P.Element is not the default class for elements, but P.element_class is. > In subcategories of Sets, such a C.Object > should be an instance of Parent. I think the category should not provide a concrete base class for its objects, but should keep providing an abstract base class. Note the difference between the element-parent relation and the object-category relation: In the vaste majority of use cases, all elements of a fixed parent are implemented using the same class. But in the vaste majority of use cases, different objects of a category are implemented using very different classes. It makes sense that all these different classes share one abstract bases class provided by the category, but this is what is already the case. > This would allow for a notion of "super-parent classes": the super-parent > classes of a parent class P would be the Ci.Object where Ci are the > super-categories of C. (This is a dynamic version of inheritance between > parent classes.) If you talk about abstract base classes, this is already the case. > At first sight, this would be a convenient way to > shortcut step 5, which for a given element x awkwardly "looks up methods of > elements of objects of supercategories of the category of the parent of x", This is not what is currently happening. C.element_class is one single abstract base class for elements, and the methods being looked up there are looked up in the usual Python way. Once C.element_class is created, there is no need to look up supercategories again. 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.
