On Wed, 25 Oct 2006, Steven Schubiger wrote:
->parse_datetime($string)
->parse_datetime( string => $string, debug => 1 );
Did both of it. But shouldn't we provide the options hash to new() instead?
Well, that depends on whether the module really needs a constructor. At
present, having an object probably doesn't do much for an end-user. Many
of the DT::Format modules allow for methods to be called as class or
object methods. Others are class-method only, IIRC. I think there are also
some which require you to construct an object.
I think all of those approaches have their uses, and individual module
authors should decide which works for the particular module they're
writing.
One thing I was thinking was that maybe eventually there could something
like this:
DateTime::Format::Natural->parse_datetime( string => $string, locale =>
$dt_local_object );
The module could use the locale to figure out what module to load, or
maybe it could construct a parser based on info in the locale. It could
also use the locale to determine the native order for various components.
Could you elaborate some more about it; I currently don't grasp the meaning
of your words provided above.
My theory is that you could use a locale to generate a parser. It's got a
lot of info on things like month names, abbreviations, etc.
Really, all it's missing is translations for words like "next", "today",
etc. The CLDR data we use for DT::Locale does in fact have entries for
"today", "tomorrow", and "yesterday", but AFAIK it doesn't have anything
for "next" or "last". Of course, there's also the question of how these
words fit into a date description grammatically.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
