On Wed, 09 Feb 2005 22:02:11 -0700, Travis Oliphant <[EMAIL PROTECTED]> wrote:
GvR: >And why would a Matrix need to inherit from a C-array? Wouldn't it >make more sense from an OO POV for the Matrix to *have* a C-array >without *being* one? Travis: > The only reason I'm thinking of here is to have it inherit from the > C-array many of the default methods without having to implement them all > itself. I think Paul is saying that this never works with C-types like > arrays, and I guess from your comments you agree with him. > > The only real reason for wanting to construct a separate Matrix object > is the need to overload the * operation to do matrix multiplication > instead of element-by-element multiplication. This is dredging stuff up from years (and layers and layers of new memories =), but I think that what Paul was referring to was in fact independent of implementation language. The basic problem, IIRC, had to do with the classic (it turns out) problem of confusing the need for reuse of implementation bits with interface inheritance. We always felt that things that people felt were "array-like" (Matrices, missing value arrays, etc.) _should_ inherit from array, and that (much like you're saying), it would save work. In practice, however, there were a few problems (again, from lousy memory), all boiling down to the fact that the array object implemenation implies interfaces that weren't actually applicable to the others. The biggest problems had to do with the fact that when you do subclassing, you end up in a nasty combinatorial problem when you wanted to figure out what operand1 operator operand2 means, if operand1 is a derivative and operand2 is a different derivative. In other words, if you multiply a matrix with a missingvalues array, what should you do? Having a common inheritance means you need to _stop_ default behaviors from happening, to avoid meaningless results. It gets worse with function calls that take "array-like objects" as arguments. A lot of this may be resolvable with the recent notions of adaptation and more formalized interfaces. In the meantime, I would, like Paul, recommend that you separate the interface-bound type aspects (which is what Python classes are in fact!) from the implementation sharing. This may be obvious to everyone, and if so, sorry. --david _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
