Front page | perl.datetime |
Postings from April 2017
Re: Subclassing DateTime?
April 30, 2017 21:31
Re: Subclassing DateTime?
Message ID: email@example.com
> On April 29, 2017 at 8:08 PM Zefram <firstname.lastname@example.org> wrote:
> Thomas (HFM) Wyant wrote:
> >It seems to me that in at least some such cases subclassing
> >DateTime would be a better alternative.
> You've run into the terrible factoring of the DateTime system. All three
> of the modules you named already suffer from it, but subclassing DateTime
> would make things worse. For subclassing to be the right answer,
> the objects of your classes would have to be everything that DateTime
> objects are, plus something that you're adding. But one of the things
> that DateTime objects are is Gregorian, which your objects are not.
Well, before I adopted the nasssty Hobbitsesss calendar I wrote my own never-published Shire Calendar module that _was_ in fact a subclass of DateTime. It overrode a pot load of public methods, of course, plus private methods _maybe_future_dst_warning(), _month_length(), _new(), _rd2ymd(), and _ymd2rd(). And, subject to the caveat that I never explored the corner cases (such as infinite times), it worked. But I was nervous about all the overridden private methods, plus the fact that I was relying on the DateTime internals (other than the ones I overrode) not to croak on a non-numeric day, plus probably other ad-hoc assumptions I do not now recall.
I suppose what I was hoping was that someone would come out of the woodwork and say something like "Oh, yes, there is a subclassing guide in such-and-such obscure place, and this list of private methods (including the ones I listed) should really be considered protected ..."
What I was trying to do before I wrote the note was to write a module (working name DateTime::Calendar::Framework) that was not a subclass of DateTime, but that passed the DateTime test suite. Then someone doing a non-Gregorian module could start from that and override what they needed to override (a lot in the case of the Shire calendar, or DateTime::Calendar::Discordian), but only public methods, and define any attributes they felt like. At the moment it passes all the tests through t/41cldr-format.t (except for t/09greg.t, which tests _rmd2yd and _yd2rmd, and which I skip, and except for a couple that access DateTime internals, which I modified). But t/42duration-class.t actually tests the subclassing of DateTime. I guess if I can't get it sorted out I can always mark the test TODO, document the associated restriction, and truck on.