Le samedi 14 mai 2011 à 01:10 +0530, Sherjil Ozair a écrit : > > > On Fri, May 13, 2011 at 11:22 PM, Vinzent Steinberg > <vinzent.steinb...@googlemail.com> wrote: > On 13 Mai, 15:04, SherjilOzair <sherjiloz...@gmail.com> wrote: > > I was thinking of making ImmutableMatrix derive from > MutableMatrix > > class, overriding its methods like __setitem__ which change > the data > > of the class, and functions like __hash__. > > This might involve making Immutable counterparts of all DS > classes, > > like ImmutableDOKMatrix, etc. However, there would be do > code > > duplication. > > This should be easy to avoid using a suitable base class. > > Vinzent > > > Sorry. By 'do' I meant 'no'. There would be no code duplication. > Or are you talking about something else ?
I think there should be a conceptual split between mutable and immutable classes that goes much deeper than just the mutability question. Mutable matrices should be considered as data structures, i.e. the CS idea of a matrix. Immutable classes should represent matrices in the mathematical sense, which implies that they are immutable, like all mathematical objects, but probably a lot of other things as well. So I'm not sure that inheritance is the best way of modelling this difference. Composition might be a better idea, cf. what LatticeOp does with sets. At least, you wouldn't have to worry about how to hide the base class's mutating methods in the immutable subclass. -- 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 sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
