Subclasses of Axes, such as PolarAxes, inherit many functions which
make implicit assumptions of rectilinear coordinates. From a design
perspective, it seems like most of these functions should not belong
to the parent class, and that, perhaps, there should exist a
RectilinearAxes(Axes) class. Essentially, Axes should contain only
the methods that are generic enough for every type of axis. If I were
to create my own subclass of Axes, I'll either have to tell people to
not use some of the methods or I'll have to re-implement them all
(which is definitely not going to happen quickly).
Subclasses of Axes, such as PolarAxes, inherit many functions which
make implicit assumptions of rectilinear coordinates. From a design
perspective, it seems like most of these functions should not belong
to the parent class, and that, perhaps, there should exist a
RectilinearAxes(Axes) class. Essentially, Axes should contain only
the methods that are generic enough for every type of axis. If I were
to create my own subclass of Axes, I'll either have to tell people to
not use some of the methods or I'll have to re-implement them all
(which is definitely not going to happen quickly).
Does this refactoring seem reasonable?
In general, I think this is reasonable thing to do.
However, I'm afraid that this refactoring will involve significant
efforts as the current Axes implementation implicitly assumes
rectlinear coordinates in so many places.
So, I'm not sure if any of the developers is willing to dive in, but
any contribution will be welcomed.
Regards,
-JJ
ยทยทยท
On Sat, Feb 13, 2010 at 2:23 PM, T J <tjhnson@...149...> wrote:
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net matplotlib-devel List Signup and Options