Names in time.h C extension
Markus Kuhn
Markus.Kuhn at cl.cam.ac.uk
Tue Sep 29 12:32:07 UTC 1998
Thanks for the many comments that I have received on the modernized
<time.h> C API on
http://www.cl.cam.ac.uk/~mgk25/c-time/
I'll try to respond to every comment individually, but there issue that
I'd like to address first separately: the names of the new elements.
Almost half of all comments that I received suggested that the
current namespace use of
struct xtime
xtime_*()
strfxtime()
TIME_*
be changed into something else. I received numerous alternative
proposals, and the only common thing among them was that they were
almost all different. Most of the criticism seemed to have been just a
matter of taste and not based on technical superiority of the
alternative.
The individual proposals were:
Paul Eggert:
xtime -> stime (short for "standard time", no rationale given)
Nathan Myers:
xtime_format: "To plan or arrange in a specified form"
xtime_compose: "To make or create by putting together parts or elements."
xtime_resolve: "To separate (something) into constituent parts."
Ken Pizzini:
timex
"There is an old tradition of language design that the language and its
libraries strongly avoid using identifiers starting with the letter 'x'
--- a desperate application writer can then blithely prepenend an 'x' to
all its first-choice identifiers and be safe."
John Hauser:
xtime_sleep, xtime_pack, xtime_unpack
Jake Knoppers:
timex
"I would recommend using the term 'timex'. It is a invented term, a.k.a.
coined term or neoligism, to which can be attached the apprpriate
definition as well as a note at the end of such defintion of ' Formerly
known as xtime'.
'Time' as word is used with multiple meanings and its use can quickly
become confusing and inadvertently may have unforeseen results. Having
the x precede the _resolves the ambiguity resulting from the x after _ ."
Ken Pizzini:
lists moment, instant, beat, clock, chronos, tiempo, heure, favours
chronos
Antoine Leca:
chronos is better than timex or xtime (without explanation)
Ok, here my reply:
How did I get to xtime? Well, the original type was called time_t and I
wanted to stay as close as possible to the traditional naming scheme of
the C API. So I removed the _t, because this is inappropriate for a
struct name. Now I had a collision with time(). My new type was an
"extended time", as it had extended range, extended resolution, and a leap
second extention, so for me
xtime for "extendted time type"
was a very obvious and nearby choice. While reviewing the comments, I
haven't found a convincing reason why any of the other name proposals
are better. Many of them are definitely worse. Some points I want to
mention are:
- Since this type is both used for clock values and for time intervals,
"time" seems to me a much more appropriate base term than anything
based on "clock". The clock_* namespace is already reserved for POSIX.1.
- The C API is completely based on the English language, introducing
terms from other languages as Antoine proposed (chronos) would
certainly break some tradition.
- I have never run into the "old tradition" that Ken Pizzini mentioned
of programming languages reserving x prefixes for application
variables. Do you have a formal reference for this, especially for
the C language. The thought that it is good practice to start all your
application identifiers with "x" sounds quite bizarre to me. I am not
too concerned about remote chances of name collisions with a small
number of applications, as there are many simple tools out there to
automatically replace identifiers in software.
- the type can also be used for many things that can be described
as non-standard times (TIME_MONOTONIC comes to mind), therefore
I don't see at all the special appeal of stime (for "standard time").
- I was surprised that suggestions that I had expected were not made:
mkxtime would follow closer the traditional naming (as I did with
strfxtime), and the traditional C API does not use underscores
inside words (I was more influenced by POSIX.1b "tradition" here)
anyway. Nathan Myers' proposal xtime_format instead of strfxtime
goes even in the opposite direction, imitating more OO-style naming
conventions instead of preserving the old style. I'd leave these
ambitions to those who write the Python, Ada, Java, and C++
bindings for these functions.
- I used "delay" instead of "sleep" only because I feel that sleep
implies that the process is suspended or that the processor is
put into a sleep mode, while delay does not imply any such
implementation detail. There is some tradition for sleep
in the sleep and nanosleep POSIX system calls, but I
felt that an OS-independent programming language should not
imply implementation details such as sending the process into a
sleep state. Therefore I considered the Ada and Turbo Pascal
"delay" statements to be closer related and more appropriate
as a source for the name.
- xtime_pack and xtime_unpack has for me at least a very different
connotation. For me, packing and unpacking sounds more like
shuffling bits around into a more compact arrangement (analog to say
Ada's "packed arrays"), and does not imply the application of
time zone algorithms, etc. C programmers are familiar with mktime,
so "make" seemed to me much more intuitive. The struct tm
representation is referred to in the standard as a broken-down
time format, therefore something based on breakup seemed to me the
closest and most obvious choice for the name of the inverse
function of "make". The existing practice of localtime() and
gmtime() is not useful here, as the name there was completely based
on the specific time zone.
Frankly, I don't care at all about the names, I am much more interested
in the functionality, but I am also not convinced why any of the
alternative proposals I have seen so far is better than what we have at
the moment. Therefore, I haven't changed anything here yet. The
committee is probably anyway going to rediscuss this issue, no matter
what we submit ... ;-)
Markus
--
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>
More information about the tz
mailing list