On 06/23/2011 03:49 PM, Benjamin Root wrote:
Hello all,

I am working to make mplot3d feature-parity with regular axes objects. I have come across a possible design flaw with the CallbackRegistry.

Many of the Axes3D methods are merely wrappers around Axes methods letting it do the work for x and y axis and then let Axes3D do the same for the z axis. In Axes.cla(), self.callbacks gets a CallbackRegistry of signals named "xlim_changed" and "ylim_changed". However, once that is set, it does not appear to be a way for me to add another signal of "zlim_changed" in Axes3D.cla(). I could replace self.callbacks with a new CallbackRegistry, but since there is a lot of interveaning code between that first initialization of self.callbacks and coming back out of Axes.cla(), I worry that some callbacks may have been registered by then and would get eliminated in the process.

Is there a recommended way around this? Or maybe this is more evidence that we should move towards the use of a dictionary of axis objects and make Axes functions more agnostic to the number of axis?
I don't know if there is a way around it as the code currently stands. Your proposal here:

https://github.com/matplotlib/matplotlib/issues/379

seems like one way out. Then the code that creates the CallbackRegistry in Axes.cla() could iterate through all the axes and create a callback type for each of them.

However, to step back from this, I've never quite understood why it was necessary to have a fixed set of callback types in the CallbackRegistry to begin with. It seems to me it comes from a history of callback registry classes I've seen in more static languages (such as libsigc++). We could just as easily create new signal types on the fly as they are registered. You lose some error checking, I suppose, if the caller and receiver don't agree on the names, but seems like a small price to pay.

Mike

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to