Re: let's keep printf, puts, and scanf

[Mike Miller]

On Wed, Apr 20, 2016 at 13:04:17 -0700, siko1056 wrote:
> Dear Mike and jwe,
> 
> My intention was neither to vandalize Octave, nor to break the API today.
> The cset got backed out, so there is no need to hurry now.

Yes, no harm done, we just noticed this sudden change right away and
thought it a little too major to be made without prior discussion.

> While adapting the documentation, I realized, how many redundant functions
> Octave has to do the very same thing:
> 
> puts (str) === fputs (stdout(), str) === fprintf(stdout(), "%s", str)
> printf(...) === fprintf(stdout(), ...)
> scanf(...) === fscanf(stdin(), ...)
> 
> and some more.

True.

> Another observation is, that the Octave language has the nice feature to
> make 2 real implementations and 4 convenience m-file wrappers to get all the
> work done. Instead Octave currently provides 6 "real" (more redundant)
> implementations in file-io.cc. Means, if any serious error is detected, the
> code has to be touched more than once! Needless to say, that the source file
> with important code is bloated up to 3k lines of code, so it's harder for
> newcomers to get into it.

True. That's why I suggested it might make sense to turn some of them
into m-file wrappers, just not labeled as deprepcated. In #octave, jwe
made the point that these functions have hardly had any bugs reported at
all and the code, even though it is in C++ routines, is still very small
and easily maintainable. They are mostly wrappers around octave_stream.

> There was the argument, that C programmers should feel "home" with these
> convenience functions, but I don't, see for example:
> 
> fputs (fid, str) vs. int fputs( const char *str, FILE *stream )

True.

> Finally Matlab does not implement these functions, maybe of good reason,
> too. So the compatibility argument doesn't apply.

True. But we do have several functions that are based on standard C
functions that Matlab does not provide.

> The only argument to leave these function into Octave is, that these were
> there for a long time, and all of us got used to these functions. An
> argument, that should never be underestimated! My bad. Even the C API is not
> able to get rid of this redundancy, as so many programs rely on it.

Not the only argument, I think convenience and similarity to the C
standard library is a big benefit. For example I would prefer to use
printf over fprintf even though it can be called without a file
descriptor.

> My intention was to get the users gently away from redundancy Octave really
> doesn't need (I mean what is the difference in typing "printf" or
> "fprintf"). With a major release every year, the functions will not be gone
> till 2020, but the code is easier to learn now!

Personally I think we should keep printf forever, there's no reason to
get rid of it, it's a useful convenient wrapper to have, yes even though
fprintf without a file argument is the same exact thing.

> @Mike: you mean varargin{:}?
> http://hg.savannah.gnu.org/hgweb/octave/file/96518f623c91/scripts/deprecated/usage.m
> Can you explain, what this does better? I would like to mention this in
> https://www.gnu.org/software/octave/doc/v4.0.1/Variable_002dlength-Argument-Lists.html
> if it is not documented elsewhere.

Yes, varargin is a cell array while varargin{:} expands to a cs-list,
which is what is necessary for the elements of the cell array to be
interpreted as distinct arguments.

  args = {"one", "two", "three"};
  func (args)

vs

  func (args{:})

The first calls func with a single argument which is a cell array, the
second calls func with 3 arguments.

> Again, I did not want to offend anyone, or break anything! But yes my cset
> was way to rude.

Again, no major harm done! :)

-- 
mike