Hi, On Tue, 2 Feb 2010 17:40:55 -0800 (PST) kcrisman <[email protected]> wrote:
> This is another reason for us not to get all finicky about structure, > but just add the functionality. If we wait for someone to > recategorize simplification/expansion (or to write it natively in > Sage), problems like this will keep showing up. The philosophy of > Sage was to do it, not to wait for perfection, I think. I am all for the "just do it" approach, as long as the backward compatibility requirements are dropped from such code. Otherwise, if we just keep adding code, it will be a nightmare to even try to keep it working across versions. Going back to this specific example, wrapping each maxima function with a method of the sage.symbolic.expression.Expression class means that we commit to supporting this interface for some time. Even if we decide to do things differently, we will have to replicate every single quirk of maxima. I suggested to keep all the maxima simplification functions behind a wrapper class, and provide convenient access to them without the explicit ._maxima_(). ... .sage() calls. This gives users an easy way to call these methods, and frees us from the backward compatibility problems since it's clear these are maxima functions. I wrote such a wrapper just now, but I have to get ready to leave for work. I'll open a track ticket for it today when I get the chance. Cheers, Burcin -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
