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

Ron writes:

> 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'd prefer set_calendar(calendar) and set_month_names(language,month_names). Completely decouple the calendar from the month names.

> I'm astonished you think sub-classing is inelegant and clumsy

Real-life example: I have French and German names in my tree, so I need French accents (acute, grave, etc) and, maybe one day, German umlauts. So I have to create new classes for French and German, and then some sort of multiple inheritance class FrenchGerman ? 

Non-real-life: tomorrow I receive a new tree in Swahili, which requires a FrenchGermanSwahili class. The day after, my long-lost Tibetan cousin emails with his tree. He has data in Tibetan, Thai, Manipuri, Konkani and Marathi, so do I create a new class named FrenchGermanSwahiliTibetanThaiManipuriKonkaniMarathi ?

Yes, that's of course an extreme, contrived and absurd example.

Please don't take any of my comments as being negative. DateTime::Format::Gedcom is already a worthwhile and useful module. GEDCOM parsers seem easy at first glance, but many have given up after facing the nitty-gritty bits, the "ifs and buts" and the edge cases !

Must sign off now, there are some angels dancing on the heads of pins that I have to count ...

Mike Hamilton
(in Melbourne)



-----Original Message-----
From: Ron Savage [mailto:[email protected]] 
Sent: Thursday, 15 September 2011 2:49 PM
To: List Gedcom
Subject: RE: Announce: DateTime::Format::Gedcom V 1.00

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