On Fri, Oct 31, 2008 at 6:46 AM, Brian Granger <[EMAIL PROTECTED]> wrote: > > One design pattern that I see in many places in sympy is that other > objects are not very encasulated. Let me give an example: > > Take printers. My initial expectation is that each object itself > would be responsible for knowing how to print itself in various > formats. I would handle this using an informal protocol like this: > > class Foo(Basic): > > def _print_str_(self): > return self.__str__() > > def _print_latex_(self): > # return the latex rep > > But, in sympy, the printer class has all of these methods for all the > classes that need to be printed. Why is it done this way?
See issue 908 for some details. ( http://code.google.com/p/sympy/issues/detail?id=908 ) > The difficulty is that if I implement a new subclass of basic, I also > have to add methods to the various printer classes. This seems a bit > silly as 1) it really breaks encasulation 2) it spreads the code for > an object all over the code base Well the encapsulation is just different, its an action on the object. There are a lot of special things that is going on in some of the printers, such as how each printer would like to represent a paren. Rather than making all the code know this it is "encapsulated' in the printer. I believe this is pretty standard in the Model, View, Controller world. On the flip side this design does make it much easier to make a new printer. If I have some special coding environment I don't have to go through every class and add _print_foo someplace, I can do it all in one place. Unfortunately there is a bit of a bug in the design, one can't just overload __str__ with a printer because the default seems to call that, we should probably make __repr__ the default. > > This is related to the work I am doing with sympy in the following > way. I have a dagger class (Hermitian conjugate). It would be nice > if all sympy classes could simply declare a _dagger_ method that > returns the actual dagger of self. But, this design seems to go > against the design patterns in sympy. There is precedent for this, for example all the _eval_foo stuff or the conjugate method. > > So, why doesn't sympy use more informal protocols to enforce > encasulation rather than spreading the logic for an object all over > the place? Do you have some examples of these protocols? -- Andy > Cheers, > > Brian > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sympy?hl=en -~----------~----~----~----~------~----~------~--~---
