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.
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). 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). Cheers, Mike Hamilton
