Vicente J. Botet Escriba wrote:
Le 07/05/13 12:46, Vicente J. Botet Escriba a écrit :
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<serial, unchecked> is an unchecked serial date. It corresponds +/- to the N3344 date suggestion. date<ymd, checked> 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<serial, unchecked> 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 :(.
That possibly modifies ud. Spelling it "try_set" will be clearer (and shorter!). The benefit of this approach is that the checking is not wasted; the result is stored in ud. The downside is that ud is still unchecked, so the checked characteristic is lost except from context. Thus, creating a date<serial, checked> from a date<serial, unchecked> would be ideal, but hardly fits as a member function of the latter.
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<serial, unchecked> dd=...; date<ymd, unchecked> yd(y,m,d); if (yd.is_valid()) { // CHECK dd = yd; // xx } else { // yy }
That should probably be in addition to try_set(). That is, both have their uses, so choosing between them is problematic.
Instead of using explicitly date<ymd,unchecked> we can use a make_essence() factory that returns some kind of tuple essence_date<year,month,day> that is not a date, but its essence. It contains everything needed to build a date.
That sounds like Howard's ymd struct idea. The latter name is certainly more convenient and specific than "essence". Nevertheless, I understand that you're trying to be abstract here.
This essence should be implicitly convertible to any date. The make_essence_date() factory supports all the different orders of parameters.
Presumably, that also would include day-of-year, week-of-year, and other, similar constructs.
The operator/() expression would also create an essence date.
// -------------- //No validity check is done.
date<serial, unchecked> ud = make_essence(y,m,d); date<serial, unchecked> ud1 = m/d/y;
If s/make_essense/make_date/, that looks very workable.
This essence dates support date validity, that is provides a is_valid() function.
// -------------- // Validity check done when is_valid() is called on essence.
date<serial, unchecked> 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;
That makes sense. serial_date<checked>(essence) can call essence::is_valid(), so the validity checking logic is only one place.
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, 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<iso_ordinal> &&); date(essence<iso_week> &&);
After doing some trials, it seems that the essence essence<T> class is equivalent to date<T, unchecked> :).
Here you've taken an unexpected turn, though looking back at the options you mentioned for the representation axis, it shouldn't have been unexpected. I was thinking your make_essence() would take various arguments, including day-of-year and similar special cases, convert them to ymd values, and the various date classes would construct from that information. ymd is likely not the best intermediate format of the information for every representation. A date<iso_week,*> date would convert trivially from an essence<iso_week>, so if the make_essence() overload, that builds an iso_week value, returns an essence<iso_week>, then creating a date<iso_week,*> can be optimally efficient. The approach seems good. Each date class can focus on its best features and leave others to other classes. There's one piece missing, however. You haven't discussed date type conversions. [From this point, I'll s/essence<Rep>/date<Rep,unchecked>/ to correspond to your findings and avoid the awkward name "essence".] Should date<Rep> be the intermediary for conversions, too? That is, does each date type provide a get_rep() accessor that returns a date<Rep,unchecked> from which another date type can be constructed? Can we make such conversions implicit? With delegating constructors, I think so: struct some_date_type { some_date_type(date<ymd,unchecked> const &); ... template <class Date> some_date_type(Date const & _other) : some_date_type(_other.get_rep()) { } date<my_ideal_rep,unchecked> get_rep() const; }; That means that no date type need know about the rest, yet they all can interconvert. Even user-defined date types can participate in this interoperably. date<Rep,unchecked> could be extended for a user-defined representation, but the standard date types need some help to convert from it. You'd start with a customization point: template <class Rep, class Checking, class Rep2> date<Rep,Checking> make_date(date<Rep2,unchecked> const &); Then, the standard date types need an appropriate constructor: template <class Rep> some_date_type(date<Rep,unchecked> const & _date) : some_date_type(make_date<MyRep,MyChecking>(_date)) { } So long as make_date() is specialized for a particular Rep/Checking/Rep2 tuple, then a standard date type can be constructed from a date<Rep2,unchecked>. Interestingly, given that customization point, the date classes now only need a move constructor and that templated constructor to support all representations. That is, all of the conversion work moves to the make_date() specializations. Indeed, a standard date class can look like the following yet support all of the argument combinations and interconversions: template <class Rep, checking_type Checking> struct date { date(date const &); date(date &&); template <class R, class C> date(date<R,C> const & _date) : date(static_cast<date<R,unchecked>>(_date)) { } template <class R> date(date<R,unchecked> const & _date) : date(make_date<Rep,Checking>(_date)) { } date & operator =(date const &); date & operator =(date &&); template <class R, class C> date & operator =(date<R,C> const & _date) { date(_date).swap(*this); } explicit operator date<Rep,unchecked>() const; }; Of course, that means the only way to create an arbitrary date type from a particular argument list is via make_date(), so other constructors may be desirable. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.