octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Keeping both tmpnam and tempname?


From: Daniel J Sebald
Subject: Re: Keeping both tmpnam and tempname?
Date: Tue, 07 Oct 2014 14:24:53 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 10/07/2014 02:06 PM, Philip Nienhuis wrote:
Mike Miller wrote
On Mon, Oct 06, 2014 at 13:50:21 -0700, Rik wrote:
Should Octave continue to keep both tmpnam and tempname in the global
function namespace?  tempname is the function name that Matlab uses.
tmpnam is the C function name for the same behavior.  We have both and
one
is just an alias for the other.  It seems like we could unclutter things
a
bit by agreeing to just keep the Matlab compatibile name "tempname".

I'm usually in favor of keeping extra functions that match the standard
C library.

In this case, we have "tmpnam" which is providing the functionality of
both of the libc functions "tmpnam" (which is like Matlab's "tempname")
and "tempnam", depending on how it's called. Then we also have "mkstemp"
and "tmpfile". I'd vote for getting rid of "tmpnam" unless there are
strong reasons for keeping it for compatibility.

What is exactly the problem with keeping aliases; can't tmpnam() remain to
be a simple wrapper for tempname, or vice versa as it is now? It doesn't
seem to be a big maintenance burden.

I'm all for keeping things simple where reasonable, but removing tmpnam will
lead to a number of code changes, also in OF packages. Does the benefit of
that little bit of uncluttering outweigh the work of removing tmpnam
everywhere in Octave code (inside and outside of core Octave)?

Looking in the respective help strings, I see that mkstemp, tmpfile and the
tmpnam/tempname duo each behave slightly differently. So I'd feel there seem
to be better opportunities to cut down on complexity.

The other thing is that I feel that Octave shouldn't try to be a verbatim
copy of Matlab.

I agree with that. But what I would say about languages in general is that often the expectation is the uniqueness of function of a command, that if there are two different commands they are different in some way.

A person often doesn't memorize commands. For example, one sort of knows there is command for getting a temporary file name, they've used it before, so they look for something like

"help tem[tab]"

octave:4> help temp
temp/            temparticle.txt  temp.png         temptemp.txt
temp2/           tempdir/         tempsave.sts/    temp.txt
temp2.png        tempname         tempstuff

then

octave:4> help tempname
'tempname' is a function from the file /usr/local/src/octave/octave-polygcd/build1/../octave/scripts/miscellaneous/tempname.m

 -- Built-in Function: FNAME = tempname ()
[snip]
     See also: tmpnam, mkstemp, tempdir, P_tmpdir, tmpfile.

and the user sees "tmpnam" and wonders, "Oh, what's different about that command?" After some reading they find it is the same command.

Now, if there are to be aliases, I'd say make it clear rather than obfuscate. Identify they are aliases somehow that saves a lot of reading:

     Alias: tmpnam
     See also: mkstemp, tempdir, P_tmpdir, tmpfile.

But as for the tmpnam/tempname debate. It looks like tmpnam came first because the documentation for "tempname" refers to "see tmpfile". I'm assuming tmpnam and tmpfile were an original pair. So to have "tempname" associated with "tmpfile" as opposed to "tempfile" seems odd.


A few weeks ago I saw strmatch() being deprecated, w/o an apparent reason
(or I missed that discussion);

If it were a unique function, that is a different subject than aliases.

Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]