RE: Announce: DateTime::Format::Gedcom V 1.00

[email protected] (Ron Savage) Thu, 15 Sep 2011 14:49:20 +1000
Newsgroups perl.gedcom
Message-ID <[email protected]>
Hi Mike

On Thu, 2011-09-15 at 12:28 +1000, Mike Hamilton wrote:
> I'm afraid Mike Elston has totally nailed it when he writes "These are not languages, they are fundamentally different calendars" (re. Gregorian, Julian, Hebrew, French, Roman and Unknown). It's obvious (now!), but I admit that the penny didn't drop for me even though "Gregorian" and "Julian" in particular are dead giveaways.

Sure.

> Simply put, calendar != language. I suppose one could (in theory) have a date in the Swahili language using the Hebrew calendar.
> 
> >> So, my very simple suggestion is that month_names_in_dutch(), month_names_in_french() [...] 
> >> be replaced with month_names_in(language).
> >
> > The trouble with this is what does the one true method do with this language name parameter?
> > 
> > For instance, if it used it as a key into a hash of month names per language - the 
> > most obvious choice - how would that hash be extended with new languages?
> 
> With "getter" and "setter" methods: get_month_names(language) and set_month_names(language).

That's a promising idea. I'll have a look more deeply tomorrow, but
right now I'd say that'll be the technique I switch to. Thanx.

I think it'd be set_month_names($calendar, $array_ref_of_names), which
would store those names into the pre-existing hash of default month
names per calendar.

> I do hope that you may yet reconsider your preference for hard-coding the language names into the method names. Also, subclassing is IMHO a very inelegant and clumsy solution. If need be, a user could create their own month_names_in_swahili() which would return get_month_names(swahili).

Some default names, e.g. Gregorian, will be hard-coded (surely).

I'm astonished you think sub-classing is inelegant and clumsy, although
I certainly concede vast amounts of code have been written in such a way
that it's awkward to use. I would claim that's not the fault of the
sub-classing concept, but of those specific implementations.

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622