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.