Hi, just wanted to mention that Travis has started a ticket on this a while ago: http://trac.sagemath.org/ticket/18066 IMHO we really need to do some proper OOP here, with contracts and abstract methods, if we want people to keep adding combinatorial Hopf algebras and the likes to Sage without having to bug Nicolas for private lessons. This is also important for tickets like http://trac.sagemath.org/ticket/17096 where I'm trying to figure out what methods we can rely on a ModuleWithBasis to have.
Best regards, Darij On Wed, Aug 26, 2015 at 4:46 PM, Simon King <[email protected]> wrote: > Hi Nicolas, > > On 2015-08-26, Nicolas M. Thiery <[email protected]> wrote: >> So far CombinatorialFreeModule has been meant as a concrete >> implementation of a ModulesWithBasis, with a specific data structure >> for its elements. > > Seriously? Then please do > grep "CombinatorialFreeModule)" -R src/sage > and > grep "CombinatorialFreeModule," -R src/sage > and you will see how many classes are derived from CombinatorialFreeModule. > > So, the reality seems to be that people consider CombinatorialFreeModule as a > base class. > >> 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. > > If CombinatorialFreeModule would officially be recognised in its current > rôle (i.e., as a parent base class), then the approach should be to cythonise > it, so that all the operations on the elements that use code provided by > the parent base class get a decent speed, and additionally the code provided > by the parent base class should not rely on a specific implementation of an > element class. > >> I see two reasons why this latter point could be annoying: >> >> ... >> >> - 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, ...) > > Customisation of the string rep of elements should be the job of a base > class for elements, relying on a public API of the parent. But please > let this element base class by cythoned, because speed and cdef > attributes typically matter for 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. > > If the code in the methods of CombinatorialFreeModule would not rely on > implementation details (i.e., underscore attributes) of > CombinatorialFreeModule.Element but on proper methods (that may very well > be required abstract methods), then we wouldn't need an adapter. > > So, in short, it is convenient that CombinatorialFreeModule comes with > CombinatorialFreeModule.Element, so that it is fairly easy to create a > new combinatorial free module. However, it would be more convenient to > allow for freedom in the implementation of its elements. > > Best regards, > Simon > > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-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-combinat-devel. > For more options, visit https://groups.google.com/d/optout. -- 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.
