* Dave Rolsky ([EMAIL PROTECTED]) [21 Mar 2003 06:55]:
> How about changing "zero" to "extra" or something like that, just to
> indicate that it's for generic extra parameters. [...]
Check!
> The "correct_years" parameter should probably go away. It's _way_ too
> specific to one format (MySQL).
Well, any format that has two digit years. Still, abolished.
> Instead I think there needs to be a "post-process" callback allowed,
> something that gets the paramaters _and_ the original string being
> parsed, and is expected to return the parameters, along with any
> modifications. This could probably just be the "on_match" callback.
Hmm. Yes. No. Yes. No. I'd like for on_match to be able to happen
without having to return anything.
> The create_class() method needs to be able to create multiple methods in
> the new class. So something like this maybe:
[...]
> parsers =>
> { parse_datetime => { specs },
> parse_date => { specs },
> ...
> }
I like it. Though it will be:
parsers => {
parse_datetime => [ specs ],
parse_date => [ specs ],
},
as I'm dropping hash form. Though it would be accepting:
parse_datetime => { spec },
aka parse_datetime => specref,
> Does create_parser() have to be recursive? It seems too clever to me.
I have a tendency to think recursively. 'Fixed' =)
> And it makes that one method too long. I think it could be moved into
> several different methods, and that'd make the code much clearer. I
> expect that this area will probably expand in the future.
Yes. The 'simple' case is now its own method, and the more complex ones
are either being completely modified or dropped.
Bare in mind that 0.22 was just what I wrote before any sort of
refactoring. I generally need a decent sized break before refactoring,
to clear my head of any assumptions (one of the useful things about
having a bad memory). That said, I happily accept your criticism.
> I'm not sure why you look at the return value of on_match and on_fail.
> It's not documented anywhere.
Due to other changes it was dropped. There was a reason, it doesn't
matter now =)
> In general, it looks good. I'm a bit concerned about its dual nature,
> though, in that in can be used directly by users as well as module
> authors. I think this could be made more palatable by re-arranging the
> docs a bit and clearly separating them into "FOR END USERS" and "FOR
> DateTime::Format MODULE AUTHORS", in that order.
I'm still thinking it's mostly for module authors rather than end users.
It just looks the other way due to the order in which it was written =)
Though I can see why and how end users could use it. Hmm.
Check.
[...]
I do appreciate these notes. You've got a good sense of design, Dave.
Expect an interim release at some point tonight.
Somewhere around TZID=Australia/Sydney:20030321T230000
Or earlier. When I've got to another stage.
cheers,
--
Iain.
