> > 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 > > We may have a situation where implementation needs functions f, g and h, > and "interface" is something like def do_a(x): f(g(x)) and def do_b(x): > g(h(x)). (Example: maximal_sublattices() and frattini_sublattice()). > > But even then the question remains: why a class for the Hasse diagram? > I.e. Poset could have a variable _hasse_diagram of type DiGraph. Then > Poset would have _f(x), _g(x) and so on as an implementation. >
We want the HasseDiagram class for those methods which do not make sense for a general DiGraph, but do for posets. We also don't want this to be (only) in the Poset class either; see above. > > For example minimal_elements() of a Poset is just a sources() of DiGraph > wrapped. Do we need two-phase wrapper? > Not really, but some of the methods of HasseDiagram are probably still around because they previously did more than simply wrapping a DiGraph method. It also can be useful to have these aliases so HasseDiagram and Poset have the same API. Best, Travis -- 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.
