Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

[Alan W. I. <ir...@be...>]

On Sat, 9 Nov 2002, Joao Cardoso wrote:

> I agree. plshades() is a good direction. Dont' remove/redefine old API
entries, instead we must provide new/easier to use API entries. With time,
we can even put a plwarn() in the old API, saying that they can be replaced
with the new one, and will eventually be removed.

Some proliferation of API like this at the C level is probably worth it. But
the interfaces also have a role that can be played.  For example, in my
user-friendly python interface, I define a lot of different simplified API's
for plcont, plshade, and plshades without having to use different names. It
is extremely easy to do this in python because it is an object-oriented
language.  Since C++, java, tcl (via itcl), and even perl have OO, then it
should be easy to translate what I have done in python to those other
languages as well.

> > I understand your concerns here, but OTOH we shouldn't be afraid to change
> > if there are compelling reasons to do so and we give plenty of warning to
> > our users.
>
> warnings is not enought, if users have a big amount of software they must
> rewrite.

They also have the option of sticking with an old stable version such as
PLplot-5.1.0 so "must" is too strong a statement.  The exact same debate
often rages for the Linux kernel with e.g., binary module makers such as the
nvidia video card company wanting no change.  But Linus refuses to be
constrained by such arguments and suggests those who want the old stable
kernel API should stick with that old stable kernel version.  The result is
an evolving kernel that remains a lot cleaner and easier to maintain than it
otherwise would.

However, that said I do appreciate the concern expressed by you and Maurice
so *when the time comes* we should also discuss the option of adding a whole
new set of plplot 3D calls named the same way as the old-fashioned calls but
with a trailing "u" in the name standing for uniform 3d API.  But let's
bring up this "add API" versus "change API" discussion again only if/when
this becomes relevant.

For example, I am only interested in making this change if the new API
contains the possibility of nx(y) or ny(x) for *all* of our 3D calls.
That's the "killer app" feature for me.  This capability has long been a
standard feature of gnuplot.  It is needed for my equation of state data
at low temperatures and high densities where no equation of state results
can be calculated.  Right now for PLplot I am forced to extend the data into
this forbidden zone using a constant value, but the results look fairly
ugly and are a bad advertisement for PLplot.

Come to think of it, right now I guess it would be possible to extend the
x(ix,iy) and y(ix,iy) arrays with constant values as well.  I haven't tried
this, but it might give a nice looking result for plcont, plshade, and
plshades with the pltr2 interpolator (which deals well with x(ix,iy) and
y(ix,iy)) passed as an argument.  But if that worked, I would also need a
new API for plot3d, plmesh, and plsurf3d to allow them to accept a pltr
pointer and use it properly inside.

Of course that possibility is part of the "best API" discussion that I
hope we continue to have.

Alan