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
