Keeping both tmpnam and tempname?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Keeping both tmpnam and tempname?

Rik-4
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".

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Keeping both tmpnam and tempname?

Mike Miller
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.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Keeping both tmpnam and tempname?

Philip Nienhuis
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.
A few weeks ago I saw strmatch() being deprecated, w/o an apparent reason (or I missed that discussion); I can only surmise that it is done because ML advises against it for some years now, yet it is still present in ML r2014b. However, strmatch is so useful that at my workplace the Matlab addicts have even made a strmatchi().

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Keeping both tmpnam and tempname?

Daniel Sebald
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 | Threaded
Open this post in threaded view
|

Re: Keeping both tmpnam and tempname?

PhilipNienhuis
Daniel J Sebald wrote:
<snip

> 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.

"A lot of reading"?  it still fits on one line.

If you mean to say that all those functions serve largely the same
purpose but differ only in details, why not combine them into one with a
few more options than the ML equivalent? That would help clean up more
(maintenance) than straightforward aliases.

> 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.

My point is rather that there is probably quite a bit of code around
having tmpnam, that needs to be changed just to clean up a bit (IMO) of
clutter w/o much maintenance overhead.

tempname is the ML equivalent, so I suppose it has been implemented
later for the sake of compatibility.

BTW, Octave's P_tmpdir and tempdir have about the same issue; but I
surmise these commands are used less frequently.

OK I shut up now, I've made my point.

Philip


Reply | Threaded
Open this post in threaded view
|

Re: Keeping both tmpnam and tempname?

Mike Miller
On Wed, Oct 08, 2014 at 09:39:45 +0200, Philip Nienhuis wrote:
> Daniel J Sebald wrote:
> >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.
>
> My point is rather that there is probably quite a bit of code around having
> tmpnam, that needs to be changed just to clean up a bit (IMO) of clutter w/o
> much maintenance overhead.

And that may be a good enough reason to keep both. I have done a quick
search through some Forge packages and found a mix of both names used
throughout.

> tempname is the ML equivalent, so I suppose it has been implemented later
> for the sake of compatibility.

Is there a reason it couldn't be turned into a true builtin alias rather
than an m-file wrapper? Or rather, make the builtin function be tempname
and make tmpnam be a builtin alias? That would significantly lower the
maintenance burden.

> BTW, Octave's P_tmpdir and tempdir have about the same issue; but I surmise
> these commands are used less frequently.

Not quite the same, P_tmpdir is a compiled-in constant string for what
your operating system says the default temporary directory is. But
tempdir can be redefined by setting the standard TMPDIR environment
variable.

> OK I shut up now, I've made my point.

All good points :)

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Keeping both tmpnam and tempname?

Markus
In reply to this post by PhilipNienhuis
Am 2014-10-08 09:39, schrieb Philip Nienhuis:

> Daniel J Sebald wrote:
> <snip
>
>> 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.
>
> "A lot of reading"?  it still fits on one line.
>
> If you mean to say that all those functions serve largely the same
> purpose but differ only in details, why not combine them into one with
> a few more options than the ML equivalent? That would help clean up
> more (maintenance) than straightforward aliases.
>
>> 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.
>
> My point is rather that there is probably quite a bit of code around
> having tmpnam, that needs to be changed just to clean up a bit (IMO)
> of clutter w/o much maintenance overhead.

FYI,
tmpnam is used 189 times in octave itself and 29 times in forge
pacakges.
While tempname is used 252 times (most comments and changelog, I guess 0
times here) in octave itself and 0 times in forge packages


>
> tempname is the ML equivalent, so I suppose it has been implemented
> later for the sake of compatibility.
>
> BTW, Octave's P_tmpdir and tempdir have about the same issue; but I
> surmise these commands are used less frequently.
>
> OK I shut up now, I've made my point.
>
> Philip