Hi All,
After too long ignoring this for one reason or another I have released a new
version of DateTime::Fiscal::Retail454 that works properly with the changes
Dave introduced in (approximately) version 0.64 of DateTime. However, the
fix involves overloading the routine _new in that module.
The overall problem stems from my making my package a true sub-class of DT
and adding my own attributes to the DT object. The trivial solution was to
overload DateTime's _new function. This, as we all know, is the beauty and
curse of perl.
When I asked Dave a question about DT his response included a question
asking me why I felt it was necessary to sub-class DT. I have considered
this, and have arrived at a structure for a new module that would not
require DateTime to be sub-classed. Instead, this new module would return
only strings where dates are asked for, and hide any internal DT
manipulations. However, a change of this nature would completely break any
existing code that uses DT::F::R454 (though there are none that I know of.)
There are two solutions to this: a) Rename the module itself, or b) put it
in a different namespace such as DateTime::Event or even DateTime::Calendar.
I should mention at this point that I believe packages under the DateTime
namespace imply they are sub-classes of DateTime itself and the objects
created by them can be manipulated with the same methods. That could be a
silly perception on my part.
Either option is viable since the 4-5-4 calendar is in fact a subset of a
class of fiscal calendars known as a 52/53 week year, which includes things
such as a 4-4-5 calendar as well. In fact, the IRS has an official
definition of what such a fiscal year is. I intend to write a module with a
new API that can implement any 52/53 week fiscal year calendar.
I would like the advice of the DT community at large as to what would be a
good name for such a module and what namespace it should go in. On the
surface one would say DT::Calendar, but the module would create dates for
various events such as the start and end dates for fiscal periods and
reporting dates as well as being able to answer questions such as What
fiscal period does a given holiday occur in? This would suggest that
DT::Event might be better. That said, because of the planned ability to
change from one period to another by means of methods such as next and
previous neither Event or Calendar might be appropriate as they seem
to imply a static condition and this would be decidedly dynamic. This argues
for keeping the new module in the Fiscal namespace with an appropriate
name.
Please offer your thoughts about naming such a module as well as the wisdom
of sub-classing DT.
Thanks in advance!
Jim Bacon
PS - if you have a copy of the original DT::F::R454 (version 0.01) PLEASE
DELETE IT or upgrade to the new version. V0.01 has a fatal logic flaw and
should never have seen the light of day.
