Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jonasbn (1153)

  reversethis-{gro.napc} {ta} {nbsanoj}
AOL IM: BJonasN (Add Buddy, Send Message)

Perl Programmer located in Copenhagen, Denmark. Active member of Copenhagen Perl Mongers.

Author of:

  • Business::DK::CPR
  • Business::DK::CVR
  • Business::DK::PO
  • Business::OnlinePayment::CashCow
  • Date::Holidays
  • Date::Holidays::Abstract
  • Date::Holidays::Super
  • Date::Pregnancy
  • Games::Bingo
  • Games::Bingo::Bot
  • Games::Bingo::Print
  • Module::Info::File
  • Module::Template::Setup
  • Test::Timer

and maintainer of:

  • Tie::Tools
  • XML::Conf
  • Workflow

Journal of jonasbn (1153)

Thursday May 20, 2004
06:26 AM

Date::Holidays::Abstract revisited

[ #18852 ]

I have received some marvellous feedback from one of the authors of one the Date::Holidays::* modules.

Apparently somebody has suggested making a super class to this author before, but the project stranded due to unknown causes.

So I will try to state why I think an abstract class and not a super
class is the way to go.

A super class will have to implement some methods which can be overwritten, whereas an abstract class will just define the
requirements for an inherting class.

If the super class has to implement the methods it has to be able to deliver data based on an unknown calendar. If the classes based on the super class can deliver data in a more raw format, the implementation will have to hold knowledge on the structure of the inherting classes. Alternatively it will have to hold information on universal holidays, but since determining universal holidays is close to impossible an therefor a bad idea.

The role of the abstract class is to define the general requirements and the distribution will act as documentation for adding new classes to the Date::Holidays::* namespace, if the case where the author is interested in following the suggested standard, which will be enforced by using the abstract class.

The number of lines of code in the abstract class will be small, but instead the documentation in the class will be more important, hence istries to streamline and uniform contributions from many authors, since the diversity in the different modules, makes the modules unusable in conjunction with each with out a lot of effort.

The reason why this is interesting to me is that I am working on a project where I want to be able to give the user the possibility
of using his or her own national calender.

I could finish my project just using Date::Holidays::DK, but that takes the sport out of my project and I must admit that having a collection of modules on the CPAN, which cannot be utilized together in project context is in my opinion one of the serious weaknesses of the CPAN.

Apart from the requirements and the documentation, it could be interesting to include general tests, which the Date::Holidays::Abstract inherting classes could utilize.

Any comments?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.