You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Brian Pane <bp...@pacbell.net> on 2002/07/13 07:39:10 UTC
more notes on the apr_time_t issue
There currently are four options listed in STATUS for changing
the time representation. There are vetoes for two of them. The
other are:
2) Renaming the function to get rid of apr_time_t vs time_t confusion,
but keep it ambigious and make no contract with the user about the
units represented.
3) Renaming the function to get rid of apr_time_t vs time_t confusion,
and strongly identify the type as apr_busec_t or apr_butime_t, with
an ongoing contract with users about the type's units.
Based on all our discussions of the past few days, I believe these
two options are identical in practice.
If the new time type is an abstract type, the common operations on
it will be:
- Native C scalar + and - operations for time arithmetic
(for performance and simplicity reasons)
- Macros to extract seconds and microseconds
And if it's a transparent type, the common operations will be:
- Native C scalar + and - operations for time arithmetic
- Macros to extract seconds and microseconds (to spare application
programmers the complexity of doing the shifts themselves)
I.e., no matter which option we use, I anticipate that the
code surrounding these types will look exactly the same.
The only major difference remaining seems to be the naming:
apr_utime_t (and interval variants thereof) vs apr_time_busec_t
(and interval variants thereof).
Can we come to an agreement on one of these names to bring
the issue to a close?
Thanks,
--Brian
Re: more notes on the apr_time_t issue
Posted by Aaron Bannert <aa...@clove.org>.
On Sat, Jul 13, 2002 at 01:24:53AM -0500, William A. Rowe, Jr. wrote:
> A full ADT cannot be allocated on the stack... you don't know the
> size. You will need real functions apr_time_make() to actually
> do pool allocations.
>
> Otherwise you are kidding yourself that this is really opaque.
Exactly.
> The other option is a transparent struct with one int64 member,
> but I really suspect we are digging into the overkill territory here.
Definately. Utility functions a good, full-blown ADT is silly for
something that is just a fancy scalar. I'm of the belief that it's
probably best if we just document well what the type is and how
it works (the seconds and useconds parts, how to do absolute vs
relative times/spans, etc) then migrate all our functions to the new,
more-efficient type(s).
-aaron
Re: more notes on the apr_time_t issue
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:55 AM 7/13/2002, Aaron Bannert wrote:
>On Fri, Jul 12, 2002 at 10:44:33PM -0700, Justin Erenkrantz wrote:
> > As Roy pointed out, this is partial hiding. I'm now of the mind
> > that it should be a full ADT under an abstract type.
A full ADT cannot be allocated on the stack... you don't know the
size. You will need real functions apr_time_make() to actually
do pool allocations.
Otherwise you are kidding yourself that this is really opaque.
The other option is a transparent struct with one int64 member,
but I really suspect we are digging into the overkill territory here.
Re: more notes on the apr_time_t issue
Posted by Brian Pane <bp...@pacbell.net>.
On Fri, 2002-07-12 at 23:12, Justin Erenkrantz wrote:
> > -1 for renaming any APR time functions: just rename the data type.
>
> If you go to a contract for the time, I think you need to have
> specific APR functions that go with that. My earlier example was
> that I might want apr_dsec_t as well. Therefore, to eliminate
> confusion, we have to have that type's functions strongly related
> to the type as there would be no generic time structure. It
> would be possible to have type confusion. Because, a user might
> inadvertently do the following.
>
> apr_dsec_t mytime = apr_time_now();
What's an apr_dsec_t?
--Brian
Re: more notes on the apr_time_t issue
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Jul 12, 2002 at 10:50:36PM -0700, Brian Pane wrote:
> Agreed. And that API includes:
> type_name_tbd operator+(type_name_tbd a, type_name_tbd b);
> type_name_tbd operator-(type_name_tbd a, type_name_tbd b);
Right.
> > If that bugs you (and it well might), then we need to go the
> > apr_busec_t route and rename every APR time function. -- justin
>
> -1 for renaming any APR time functions: just rename the data type.
If you go to a contract for the time, I think you need to have
specific APR functions that go with that. My earlier example was
that I might want apr_dsec_t as well. Therefore, to eliminate
confusion, we have to have that type's functions strongly related
to the type as there would be no generic time structure. It
would be possible to have type confusion. Because, a user might
inadvertently do the following.
apr_dsec_t mytime = apr_time_now();
But, wait, you want apr_time_now() to return an apr_busec_t. Will
the compiler issue a warning or an error here? In the common case,
they will both be scalar, so I think the compiler just might issue
an warning (or perhaps nothing at all).
Therefore, I think it has to be:
apr_dsec_t mytime = apr_time_dsec_now();
apr_busec_t mytime = apr_time_busec_now();
(time_ does not have to be in the function name.)
My $.02. -- justin
P.S. Try http://www.apache.org/~jerenkrantz/types.c with your
compiler!
Re: more notes on the apr_time_t issue
Posted by Brian Pane <bp...@pacbell.net>.
On Fri, 2002-07-12 at 22:44, Justin Erenkrantz wrote:
> On Fri, Jul 12, 2002 at 10:39:10PM -0700, Brian Pane wrote:
> > If the new time type is an abstract type, the common operations on
> > it will be:
> > - Native C scalar + and - operations for time arithmetic
> > (for performance and simplicity reasons)
> > - Macros to extract seconds and microseconds
>
> As Roy pointed out, this is partial hiding. I'm now of the mind
> that it should be a full ADT under an abstract type. Therefore,
> the +/- operations should be handled by an API. (For performance
> reasons, it can be a macro - say apr_time_add/apr_time_diff which
> do the obvious C scalar operations.) But, under no circumstances
> for this solution, can the user do *anything* with the value
> without going through some API.
Agreed. And that API includes:
type_name_tbd operator+(type_name_tbd a, type_name_tbd b);
type_name_tbd operator-(type_name_tbd a, type_name_tbd b);
> If that bugs you (and it well might), then we need to go the
> apr_busec_t route and rename every APR time function. -- justin
-1 for renaming any APR time functions: just rename the data type.
--Brian
Re: more notes on the apr_time_t issue
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Jul 12, 2002 at 10:55:03PM -0700, Aaron Bannert wrote:
> On Fri, Jul 12, 2002 at 10:44:33PM -0700, Justin Erenkrantz wrote:
> > As Roy pointed out, this is partial hiding. I'm now of the mind
> > that it should be a full ADT under an abstract type. Therefore,
> > the +/- operations should be handled by an API. (For performance
> > reasons, it can be a macro - say apr_time_add/apr_time_diff which
> > do the obvious C scalar operations.) But, under no circumstances
> > for this solution, can the user do *anything* with the value
> > without going through some API.
>
> Don't you think that will kill performance?
No.
#define apr_time_add(time1, time2) time1+time2
#define apr_time_sub(time1, time2) time1-time2
#define apr_time_mul(time1, time2) time1*time2
#define apr_time_div(time1, time2) time1/time2
For more complex time structures, it could be a function. -- justin
RE: more notes on the apr_time_t issue
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Aaron Bannert [mailto:aaron@clove.org]
>
> On Fri, Jul 12, 2002 at 10:44:33PM -0700, Justin Erenkrantz wrote:
> > As Roy pointed out, this is partial hiding. I'm now of the mind
> > that it should be a full ADT under an abstract type. Therefore,
> > the +/- operations should be handled by an API. (For performance
> > reasons, it can be a macro - say apr_time_add/apr_time_diff which
> > do the obvious C scalar operations.) But, under no circumstances
> > for this solution, can the user do *anything* with the value
> > without going through some API.
>
> Don't you think that will kill performance?
The VERY first apr_time implementation was an incomplete type, making it
an ADT. That was removed because performance sucked. You can't make
simple types like time incomplete.
Ryan
Re: more notes on the apr_time_t issue
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Jul 12, 2002 at 10:44:33PM -0700, Justin Erenkrantz wrote:
> As Roy pointed out, this is partial hiding. I'm now of the mind
> that it should be a full ADT under an abstract type. Therefore,
> the +/- operations should be handled by an API. (For performance
> reasons, it can be a macro - say apr_time_add/apr_time_diff which
> do the obvious C scalar operations.) But, under no circumstances
> for this solution, can the user do *anything* with the value
> without going through some API.
Don't you think that will kill performance?
-aaron
Re: more notes on the apr_time_t issue
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Jul 12, 2002 at 10:39:10PM -0700, Brian Pane wrote:
> If the new time type is an abstract type, the common operations on
> it will be:
> - Native C scalar + and - operations for time arithmetic
> (for performance and simplicity reasons)
> - Macros to extract seconds and microseconds
As Roy pointed out, this is partial hiding. I'm now of the mind
that it should be a full ADT under an abstract type. Therefore,
the +/- operations should be handled by an API. (For performance
reasons, it can be a macro - say apr_time_add/apr_time_diff which
do the obvious C scalar operations.) But, under no circumstances
for this solution, can the user do *anything* with the value
without going through some API.
If that bugs you (and it well might), then we need to go the
apr_busec_t route and rename every APR time function. -- justin