Nathaniel Smith wrote: > On Sat, Apr 28, 2012 at 7:38 AM, Richard Hattersley > <rhatters...@gmail.com> wrote: >> So, assuming numpy.ndarray became a strict subclass of some new masked >> array, it looks plausible that adding just a few checks to numpy.ndarray to >> exclude the masked superclass would prevent much downstream code from >> accidentally operating on masked arrays. > > I think the main point I was trying to make is that it's the existence > and content of these checks that matters. They don't necessarily have > any relation at all to which thing Python calls a "superclass" or a > "subclass". > > -- Nathaniel
I don't agree with the argument that ma should be a superclass of ndarray. It is ma that is adding features. That makes it a subclass. We're not talking mathematics here. There is a well-known disease of OOP where everything seems to bubble up to the top of the class hierarchy - so that the base class becomes bloated to support every feature needed by subclasses. I believe that's considered poor design. Is there a way to support ma as a subclass of ndarray, without introducing overhead into ndarray? Without having given this much real thought, I do have some idea. What are the operations that we need on arrays? The most basic are: 1. element access 2. get size (shape) In an OO design, these would be virtual functions (or in C, pointers to functions). But this would introduce unacceptable overhead. In a generic programming design (c++ templates), we would essentially generate 2 copies of every function, one that operates on plain arrays, and one that operates on masked arrays, each using the appropriate function for element access, shape, etc. This way, no uneeded overhead is introduced, (although the code size is increased - but this is probably of little consequence on modern demand-paged OS). Following this approach, ma and ndarray don't have to have any inheritance relation. OTOH, inheritance is probably useful since there are many common features to ma and ndarray, and a lot of code could be shared. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
