> > class Poset: > > def A(): > for i in ZZ: > self._B() > > def _B(): > # works on the digraph self._hasse_diagram, taking advantage > of its labelling > > I do not see where the problem is. It requires a helper function _B a > in the current design (where _B would be a HasseDiagram method), and > for the other functions that do not need to "call a function that > takes advantage of the labelling" (whatever that means) we would need > only one function (which is 99% of the time). > > Yes, that works, but it combines the concerns of HasseDiagram (the assumption of a special labeling, full access to DiGraph methods, but still knows it is suppose to represent a poset) with Poset (the frontend for the user with a custom labeling). It is not a good design because you're doing everything on the digraph, i.e., it breaks the code's locality.
> I still do not see what makes HasseDiagram mandatory. To clear any > misunderstanding, look at the following ticket: > > http://trac.sagemath.org/ticket/19659 > <http://www.google.com/url?q=http%3A%2F%2Ftrac.sagemath.org%2Fticket%2F19659&sa=D&sntz=1&usg=AFQjCNE90_jKP6_A7SccNMk1p3MJN-IJRQ> > > > It implements a Poset function that "takes advantage of the diagram's > labelling" and we don't need any HasseDiagram method, so I do not know > what you are talking about. > > TL;DR. From the code, it looks like the method should be in HasseDiagram. Good OOP is separation of concerns and locality of code. The HasseDiagram class is not mandatory, just like having classes and good design and code is not mandatory. 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.
