Daniel Yacob schreef:
> I favor the first option, but then I also favor Gregorian:: as a name
> space and no default calendar system being assumed... ;-)
Unfortunately, us kalandariophiles are a minority on this list; I
suspect Dave in particular of wanting to use DateTime for all kinds of
worldy, modern, boring stuff.
> But if that is not going to happen, would a
> DateTime::Calendar::Ethiopic::Language module really be needed or
> should we rely on DateTime::Language to know the calendar system
> and do the right thing?
No, DateTime::Language can't know about all the wonderful calendars in
the world. For most calendars (including Ethiopic, I presume) one or
two languages will suffice: one in the local alphabet, and one
transcribed to the Roman alphabet. The latter should then be included
in all language modules...
Or do the Ethiopic months have English names? (Or Italian, perhaps?)
It would be nice if one could pass for example a
DateTime::Language::Dutch object to DT::C::Ethiopic, which would then do
the right thing. Something like:
sub new {
my $class = shift;
my $args = validate( @_,
{ ...,
language => { type => SCALAR | OBJECT,
default => 'Amharic' }
}
);
...
if ( ref $args{language} ) {
$self->{language} = ($args{language} eq 'Amharic' ?
'Amharic' : 'Roman');
}
...
}
sub month_name {
my $self = shift;
return { Roman => ['month1', 'month2', ... ],
Amharic => ["\x{12XX}\x{13XX}", ... ], }
->{$self->{language}}[$self->month_0];
}
(Or move those month names to their own module DT::C::E::Language; but
that's an implementation detail. I would like to have a consistent API
for all calendars, but I don't care about the implementations.)
Eugene
