Arjen Markus writes:
> "Alan W. Irwin" wrote:
> > Hi Arjen:
> > I am very pleased you are moving ahead with the f95 interface and
> > examples. However, there is an interface issue we should discuss.
> > In the discussion of the f95 interface that you just committed in
> > bindings/f95/readme_f95.txt, you illustrated the 4 possible methods of
> > handling dimensions and integer flags. You concluded Method 2 was the
> > best, i.e., drop the redundant dimension information and treat C integer
> > flags as fortran logical variables.
> > I think dropping the redundant dimension information is a great idea that
> > also follows what we have already done for the other high-level interfaces
> > (python, java, and perl). So that eliminates Methods 1 and 4 from
> > consideration.
> > However, I would like to argue for Method 3 where we drop the redundant
> > dimension information but treat C integer flags as fortran integers. My
> > reasons are threefold:
> > (1) Consistency with all our other high-level interfaces (python, etc.)
> > will make the f95 interface easier to document.
> > (2) Some of our integer flags (e.g., the argument to pladv and many
> > more) will have to remain integer in any case since they carry three or
> > more choices. So logical arguments cannot replace all integer
> > arguments. Thus, Method 2 adds unnecessary choice that can lead to an
> > increase in user errors when they make the wrong choice of argument
> > type.
> > (3) If we extend the underlying C API so that a current integer flag
> > with just two choices becomes one with three or more choices or one with
> > 3 or more choices becomes one with just two choices, then Method 2
> > requires that you have to change the f95 interface which is both a
> > maintenance issue and an API issue.
> Okay, I agree: the names of some of these arguments suggest that more
> choices are intended even though only two are actually used in the
> underlying code. I was not very happy with the four different ways of
> calling plbin(), but I was not very happy with encoding a logical argument
> via an integer either. I suggest solving this issue via a few mnemonic
> parameters - that will indicate the intention of the argument and people
> can still use 0 or 1 if they like.
The goal of a PLplot language binding, in my opinion, should be to make the
use of PLplot as natural as possible in the programming context of that
language or environment. So, for example, I disagree with (1) above, to the
extent that it fails to comprehend the differences between programming
languages and environments. Python, didn't use to have a bool type, at least
not when the PLplot Python binding was first written, (though it does now).
Similarly, C, as most people know it, does not have a bool type, although the
C90 standard reputedly has one. C++ has one. And Fortran, in this
uncharacteristic display of industry leading prescience, has had one for 30
Alan's point that some parameters require int precision, either now, or as
possible/anticipatable extensions, is good and correct. But where there are
parameters for which the PLplot C interface uses an int simply because we
don't require the C90 standard to compile PLplot, but where the actual
concept modelled by the paramater is in fact boolean in nature, I would favor
using the host language's bool type, whatever that is.
In doing some research before making this post, I was reminded that some of
these languages which support boolean types, allow overloading based on the
type of the argument (bool or int). So, in contexts where a programmer might
fill in one argument to a call not with a literal or an explicitly named
variable, but rather just supplying a logical expression, the language can
vector to the appropriate implementation.
I don't know if that notion of type-based overloading is of specific value to
the implementation of a PLplot binding in a particular language. But my
point is, people who operate in these language envrionments are accustomed to
the distinction between int and bool, and are used to using this distinction
to effect. It is really just that C is so primitive. Even C has grown a
bool type in the C90 rendition.
Summary: IMO, any binding of PLplot to a particular language, should aim to
express the PLplot API as naturally as possible in that language. While I
like to see the various PLplot language bindings being as similar to each
other as possible, to foster "code migration by twiggling ;'s", I don't think
this need outweighs the need for fitting comfortably into the host