Hi all, Simon King (replying to my question) wrote:
> - Do the methods coming from ElementMethods always take priority over > > (override) those from the base classes? > > No, it is the other way around. > Right, and if I now understand correctly, it is because Element.__getattr__() changes the lookup order, isn't it? 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. > Let me try to summarize what you should do, and what is happening *if* > you do it: > > 1. Let P be a parent that is initialised as an object in the category C. > 2. Let E_class be a class that you wrote to implement elements of P. > 3. You would then want to have an attribute P.Element == E_class (often, > this attribute would be defined as an attribute of P.__class__, but it > is totally fine that different instances P1, P2, ... of P.__class__ > have different P1.Element, P2.Element, ... > 4. Because you have provided P.Element, P provides another (lazy) > attribute > P.element_class. This is a dynamic class with bases P.Element and > C.element_class (in this order!). > 5. C.element_class is also a dynamic class, that is obtained from the > class C.ElementMethods and C1.element_class, C2.element_class, ..., > where C1, C2, ... are the immediate super categories of C. > 6. Your elements should then be instances of P.element_class. > 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. 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. In subcategories of Sets, such a C.Object should be an instance of Parent. 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.) 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", and instead "looks up methods of elements of super-parent classes of the parent of x". I think this should be as flexible as the current C.ElementMethods, since P.element_class still would be created depending on the category of the parent, and the result of looking up methods of elements of objects in supercategories would be the same. Moreover, this way of organising code for element methods would be rather more intuitive (to me) and would avoid any choice whether to put elements in ElementMethods or in Element classes, since they would simply all be in Element classes. Unfortunately I am too busy at the moment to think about this in detail; I hope at least it does not sound like an idiotic idea. 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 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.
