I am fooling around with implementing a Date::Holidays class, which is can utilize all the modules in the Date::Holidays::* namespace.
This tasks is somewhat more frustrating than I had imagined. The list of modules I want to use are currently 6 and the number of exceptions to the normal program flow I have had to implement up to now counts: 4, this is just based on module naming conventions and other small things...
This is quite crazy since all I have working is the loading and calling of subs, which is currently tested using a set of generic tests and I had not even started to look at the test output yet at this point...
In the test suite I have 3 tests per module, with the 6 modules this ends up with 18 tests out of these 7 fail.
Some of the failures can be explained, since only Date::Holidays::DK have implemented one of my suggested additions of a dk_holidays method.
This is the current TODO list of Date::Holidays:
From processing of test results from bin/test_date-holidays_modules.t
- Date::Holidays::UK misses holidays or similar method
- Date::Holidays::FR misses holidays or similar method
- Date::Holiday::PT misses holidays or similar method
- Date::Holidays::DE misses is_holiday or similar method
- Date::Japanese::Holiday cannot be called in the expected way, since it is OOP and requires the class name (I consider leaving this module out all together)
--
- Should the holidays and is_holiday methods return return values others than undef in order for Date::Holidays to act as real super class or should I implement Date::Holidays::Super as an alternative to Date::Holidays::Abstract.
Well there is much work remaining... and possible patches and suggestions to the authors...