Re: [boost] [chrono/date] Two axes for a date design: validity check and representation and an essence date class/factory

7 May 2013


      Le 07/05/13 12:46, Vicente J. Botet Escriba a écrit :
...
Hi,
I would like to discuss about some alternatives to take in account the 
following use case
 "Reset a date if it resulting date is valid and report if this succeeds"
when we have two axes of variation on the date design.
Let me add two parameters to the possible date class.
* validity: unchecked/checked
* representation: serial, ymd(calendar), iso_ordinal, iso_week...
date is an unchecked serial date. It corresponds 
+/- to the N3344 date suggestion.
date is a checked ymd date. It corresponds +/- to the 
H.H 2011 date proposal.
WARNING !!! I'm not saying that a template class is a good thing, it 
is just to state clearly the features of the date.
N3344 suggest a date::set_if_valid_date function.
date ud=...;
if (ud.set_if_valid_date(y,m,d)) {
 // xx
} else {
 // yy
}
But if we want to do as for the date constructors we will need 
multiple overloads again for this function :(.
As show on this ML serial+unchecked dates validation could have some 
surprises.
We can get the same service building a ymd date that can provide a way 
to be validated.
//-------------
// Validity check done when is_valid() is called on ymd_date.
date dd=...;
date yd(y,m,d);
if (yd.is_valid()) { // CHECK
  dd = yd;
// xx
} else {
 // yy
}
Instead of using explicitly date we can use a 
make_essence() factory
that returns some kind of tuple essence_date that is 
not a date, but its essence. It contains everything needed to build a 
date.
This essence should be implicitly convertible to any date.
The make_essence_date() factory supports all the different orders of 
parameters.
The operator/() expression would also create an essence date.
// --------------
//No validity check is done.
date ud = make_essence(y,m,d);
date ud1 = m/d/y;
This essence dates support date validity, that is provides a 
is_valid() function.
// --------------
// Validity check done when is_valid() is called on essence.
date ud;
auto d = y/m/d;
if (d.is_valid()) { // CHECK
  ud = d;
 // xx
} else {
 // yy
}
//--------------
// Validity check done at construction of cd.
serial_date<checked> cd = make_essence(m,d,y);
//serial_date<checked> cd = m/d/y;
Summary: IMO
Having checked and unchecked dates with several representations could 
help to make dates interface more precise and concise.
Checked dates are always valid.
Dates with a specific representations would provide only, as suggested 
by Howard, only the functions that are efficient.
The use of essence dates factories simplify the interface of all the 
date classes construction. Only 1 constructor by representation needed 
independent of the parameters order
date(essence<ymd> &&);
  date(essence<serial> &&);
date(essence &&);
date(essence &&);
Comments welcome,
Vicente
P.S.The essence date classes and the contextual dates are quite 
related. I prefer to let this 3rd contextual axe of variation out of 
the current scope. I will try to integrate it soon.
After doing some trials, it seems that the essence essence<T> class is 
equivalent to date :).

Vicente