> The former is when the Poset is acting as an adapter class, and the latter > is something where there either is no analog currently on the backend (there > might be no gain because there is no analog (di)graph function or > translation cost). It depends on the situation and is just trying to be > effective code.
What I (and probably Jori too) try to understand is what should be implemented in HasseDiagram and what should be implemented in the Poset class directly. Right now the development is designed in what I think is a really senseless way: every features requires two new functions: - One on HasseDiagram which does the job - One on Poset which calls it It looks like useless work (especially since users are discouraged to use HasseDiagram). I got used to implement only one function when I need only one function. So far, the only reason I understood from conversations with Jori is that the Poset constructor (which relies on UniqueRepresentation) is too slow to be called too often. So Jori works on HasseDiagram directly to avoid this cost. While it makes sense on one's computer (I would probably do the same) it just doesn't do to duplicate everything in Sage's own source code just because the constructor is slow. Nathann -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
