On Fri, Jul 12, 2002 at 02:42:22PM -0500, William A. Rowe, Jr. wrote:
> And with (III.) above, it just makes good sense to pick new names for this
> new type, IF we are going to have a contract with the programmers about
> the representation. We can have compatibility macros until the old symbols
> are deprecated, and Aaron and others who are concerned with catching all
> instances of the old usage can disable the compat macros.
Nope, compatibility macros can't work since the claim is that people
are directly altering the values. If they used the functions, then
the complaint about backwards-compatibility would be moot.
> >VI. Brian and others have asked that we have an undefined scalar value
> > [with no contract to the users about it's representation.] Roy and
> > others
> > object, due to overflow and range considerations, and binary
> > compatibility
> > considerations [as it's all in macros that aren't updated by new
> > binaries].
>
> I really don't see a win here. Why have no contract? We aren't hiding the
> definitions within accessor functions behind an opaque type. There is NO
> type safety when you use C scalars for a type.
>
> And the code can never be binary drop-in replaceable, the time manipulation
> was all compiled into the user's code from the macros, it isn't buried safely
> inside of APR.
I maintain that it should be undefined so that on source-compatible
releases, we can switch the types. On binary-compatible release, we
can't touch it though. (Greg and Ryan have defined this well.)
I'm slowly beginning to believe that apr_time_t *should* be entirely
opaque.
#define apr_time_diff(time1,time2) time1-time2
...
But, in APR 2.0 (or the next source-compatible release), if we wanted
to we could make it a function such that (not that we would do
this example for reasons you point out later):
apr_span_t apr_time_diff(apr_time_t t1, apr_time_t t2)
{
apr_span_t t3;
t3.sec = t1.sec - t2.usec;
t3.usec = t1.usec - t2.usec;
return t3;
}
The fact that we exposed the time structure at all is the reason that
we are in this predicament. Merely changing the type name would not
be a win, either. If we make it unspecified, we have to make sure
that direct modification of apr_time_t is not allowed.
> >VIII. From all of the above came the original discussion of naming. Ryan and
> > others believe we should not change the name of the type, whatsoever.
> > The sub-argument is between a strongly defined name contract, e.g.
> > busec in the identifier, or a completely ambigious name with no
> > contract
> > of the scale's unit.
>
> And I stand on a strongly named, intuitive names that warn you not to just
> pass around seconds. That leaves us with something like;
>
> apr_time_busec_t
> apr_span_busec_t
>
> which conveys that the span is measured in buseconds.
>
> I'm suggesting the time/span before busec so we don't have to go about
> renaming EVERY SINGLE apr_time_fn() to a new type. Can we all live
> with apr_time_() functions addressing apr_time_busec_t values? Or do
> we have to go to the extreme of renaming these all apr_time_busec_fn()?
No, if you buy in the apr_time_busec_t argument, all of the functions
have to be renamed. The reason is that I can come along with a
apr_time_dsec_t implementation. If we have an explicit contract,
we MUST make the API specific to that contract. No apr_time_now(),
etc. It has to be apr_time_busec_now(), etc.
Personally, I think the proponents of the busec contract are going
to paint ourselves in a tight corner if we do find something wrong
with that implementation down the road. I would much prefer that
we allow ourselves to change implementations without changing the
API. I believe that the explicit contract solution for busec will
come back to haunt us. -- justin
