Hi! On 2015-06-08, Viviane Pons <[email protected]> wrote: > 2015-06-08 9:51 GMT-05:00 Nathann Cohen <[email protected]>: > >> To me it is not a problem of doc but a problem of code. The issue is that >> we have 99% of the poset functions in the poset/ folder, and a couple of >> them in the category/ folder. If we move everything to posets, there's no >> problem. I don't see any advantage in having poset code in a file that is >> meant to implement the category of posets. >> > > I disagree with that.
So do I. > There's some advantage: if your code only depends on > general mathematical properties of posets and not on the specific > implementation of the poset object, then it should be in the category. +1 > The reason is: sometimes you define a parent (like a set of objects) which > happens to have the mathematical property of a poset. Then it doesn't > inherit from the actual poset object but does belong to the category of > posets and you want to have access to the category methods. Exactly. And when speed becomes important (whether it does may depend on the specific application), you can still override the general code by some implementation specific code, that would best be Cythoned. 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 [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/d/optout.
