Hi! Due to #9944, #9138 and #11115, it will hopefully soon be possible to move many methods from sage.rings.ring.Ring to sage.categories.rings.Rings.ParentMethods, including cached methods.
The benefit of moving the code is that a MatrixSpace, which sometimes is a ring and sometimes isn't, could benefit from the generic ring code. And I guess MatrixSpace is not the only example of something that may or may not be a ring, depending on parameters. However, if you have an extension class derived from sage.rings.ring.Ring that does not allow attribute assignment then inheriting a cached method from the parent class of its category does have a speed penalty. So, if we want to have generic ring code via categories (and I guess we want!) then we have to choose: Either one accepts a slow-down, or one duplicates code. Then, classes deriving from sage.rings.ring.Ring would get the generic methods from there, while other rings (such as MatrixSpace(QQ,2)) will get the generic methods from sage.categories.rings.Rings.ParentMethods. What is your point of view: Should code duplication be strictly avoided? I am afraid I don't know yet how much of a slow-down we would actually see. That question is part of #11068, where I try to implement one- and twosided ideals for non-commutative rings, and the generic methods I am talking about are _ideal_class_, zero_ideal, unit_ideal and the like. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
