This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gsl Development Query


Gerard Jungman wrote:

> Look, we can all sit and play C++ compiler.  But there's no point.
> The implementation language for this project does not make a distinction
> and nobody at this end is going to make pedantic distinctions.
> People who use C libraries have to apply some common sense.
> That is a fact (unfortunate perhaps) of the language.
>
> And he did it because it was useful to write it down somewhere.
> Don't quibble about where he wrote it down.
>
> Nobody is painting any corners
> and nobody is obliged to do anything.

You are wrong.
The documentation specifies each of the data members in

        typedef struct {
          size_t n;
          size_t nf;
          size_t factor[64];
          gsl_complex *twiddle[64];
          gsl_complex *trig;
          double *scratch;
          } gsl_fft_wavetable_complex;

Application programmers can reference and modify
the private data members
of a gsl_fft_wavetable_complex object directly.
Apparently, the documentation guarantees
that a gsl_fft_wavetable_complex object
will always have this data representation and
the data members will always have this interpretation.
That means that the GSL developers
can never change the data representation
or the implementation of the GSL FFT
without breaking application programs
that depend upon this representation
and the implementation that it implies.

The GSL provides no library functions
which application programmers can use
to access the private data member indirectly.
The GSL makes no attempt to hide
the actual data representation
from the application program.
The GSL documentation makes no distinction
between the API and implementation details.
Application programmers can't "apply common sense"
because GSL application programmers
and GSL library developers don't share
the necessary information.
Application programmers would need to be clairvoyant!
And upon reading your mind and Brian's mind,
they would discover that you and he can't even agree
so how would you expect application programmers to decide
what is part of the API and what is implementation detail?

I'm not talking about anything exotic here.
All that I am talking about is simply applying
good programming practice.
It has nothing to do with any particular programming language.
Pick up a copy of "Data Structures and Algorithms"
by Alfred V. Aho, Jeffrey D. Ullman and John E. Hopcroft
or just ask any sophomore computer science student
who has recently completed a course in data structures.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]