Hi Simon! On Wed, Aug 26, 2015 at 08:05:32AM +0000, Simon King wrote: > Working on path algebras, which inherit from CombinatorialFreeModule, I > found that CombinatorialFreeModule makes specific assumptions on > implementation details of the elements of a module. > > What I mean is, for example, CombinatorialFreeModule.sum. It relies on > the assumption that all elements have a public attribute > _monomial_coefficients, > which is supposed to be a dictionary. But an underscore attribute is commonly > considered an implementation detail, if I understand correctly. That's > too intrusive, I don't want that a parent imposes my elements to be > implemented > as a monomial-coefficient dictionary. > > It seems to me that CombinatorialFreeModule tries to impose on the user > to use an element class that is a sub-class of > CombinatorialFreeModule.Element, > which is a Python class. That's too intrusive, I believe. I want to be > able to use a Cython class for elements (that's the point of #17435). > > Would you at least consider to avoid the usage of the implementation > detail "x._monomial_coefficients" and replace it by a public API such > as "x.monomial_coefficients()"? I don't want my elements to be > IMPLEMENTED based on dictionaries stored in private attributes, but of > course I don't mind to provide a public method that CONSTRUCTS such a > dictionary for an element.
So far CombinatorialFreeModule has been meant as a concrete implementation of a ModulesWithBasis, with a specific data structure for its elements. In this context, generic methods that don't depend on the data structure should be in ModulesWithBasis and the others should be in CombinatorialFreeModule. And your parent would just be in ModulesWithBasis, without inheriting from CombinatorialFreeModule. I see two reasons why this latter point could be annoying: - Many generic methods have not yet been lifted from CombinatorialFreeModule to ModulesWithBasis. That would take a bit of work to fix, but that's something we want to do at some point anyway. - There is code in CombinatorialFreeModule that does not depend on the data structure of the elements but can't be easily moved up to the category. Typically initialization code (category, base ring, customization of the string rep of elements, ...) Maybe this is calling for an additional class above CombinatorialFreeModule that would factor out this code? This would be similar in flavor to the "Adapter Classes" pattern in java (see http://stackoverflow.com/a/10170811). Note that this is already partially done by the IndexedGenerators class. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" <[email protected]> http://Nicolas.Thiery.name/ -- 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.
