On Fri, 06 Jun 2008, Michael J Gruber apparently wrote:
> We introduce analogues of graph.data.function etc. to be used as data
> sources for graph.graphxy.
> Naming is changed in order to make things more consistent with grah/graphxy.
> * rename functionxy to functionlambda (2D function given as lambda
> expression)
> * rename paramfunctionxy to paramfunctionlambda (2D parametric
> function given as lambda expression)
> * new functionxy (3D function given as textual expression)
> * new functionxylambda (3D function given as lambda expression)
> * new paramtsfunction (function of 2 parameters given as textual
> expression)
> * new paramtsfunctionlambda (function of 2 parameters given as
> lambda expression)
I hope a user reaction is welcome on this list:
- never say lambda.
- use xy to match graphxy (2D), and xyz for 3D
Here is a different approach.
Consider graph.data.
I propose that from a user interface perspective,
there was a mistake. The ``function`` class
should be a facade which should include the following
keyword arguments:
parametric = False
expression = ''
function = None
A user would then set one of the three.
Perhaps a new ``functionxy`` or even ``x2y`` (ok, I can hear
the groans) class could implement this facade. However it
would be backward compatible to just generalize ``function``.
The 3D code need never go the 2D class proliferation route:
it can start right away with a nice unified user interface.
The corresponding 3D class could be ``functionxyz`` or
``surface`` or even ``xy2z``.
Talk is cheap!
Alan Isaac
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
PyX-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyx-devel
