On Monday, July 14, 2003 John Peacock wrote: >John Siracusa wrote: >> Great, but the $64K question is: do we then get parse() and parser() methods >> in DateTime, which default to use DT::F::Simple? :) >> >A while ago, when this discussion last reared its [ugly] head, I suggested that >the base class contain methods which would call an array of potentially more >expensive parsers, until one returned a value other than undef. The default >install would only include the smallest, fastest parser and the user could add >other to the list. > >Thinking about it now, it would make the most sense to me to make >DateTime::Format be an actual class which would dispatch to the DT::F::something >modules. That way, nothing needs to be added to the DateTime class itself, if >you never need parsing.
Some good ideas are converging here. Couldn't the following all be possible: 1. DT::Format as an actual class, per John S; 2. DT::Format has parse() and parser() methods; 3. DT::Format dispatches to DT::F::XXX modules, using DT::F::Simple unless the user has called parser(). 4. DateTime also has methods parse() and parser(), per John P, which simply invoke DT::Format and hand off their params to DT::F's own parse() and parser() methods; 5. If the user doesn't call parse() or parser() from DT, then DT::F and DT::F::XXX are never invoked by DT; 6. All parsers fail (return undef) if they can't parse a string, both for good programming practice and to allow falling through to the next specified/available parser module; 7. parser() -- or parsers()? -- would let the user specify which of the available DT::F::XXX modules to use, and the order with which they are tried. - Bruce __bruce__van_allen__santa_cruz__ca__
