Re: Parsing/Formatting API

[John Peacock]

Dave Rolsky wrote:

I'm going to lay out my requirements for how this will work in order to
constrain the discussion, because I really have a firm idea of how this
needs to work.


My constraints are:

1. A module should be able to choose to implement parsing, formatting, or
both.

And as you point out, usually parsing and formatting are going to be complementary and likely will be in the same module.

2. I really want to avoid runtime module loading. This is because I have
a mod_perl bias, and with mod_perl, it's much better to load modules at
compile time

This doesn't, in itself, preclude a plug-in model for parsing modules. It merely requires they be pre-specified and pre-loaded. If I am not mistaken, there are other modules that perform magic in BEGIN blocks iff loading under mod_perl. The poor fools running mod_perl just have to limit their parsing options up front, with a conscious effort.

3. "DateTime->new( 'somerandomthing' )" is not going to happen.  This is
bad for several reasons:

 a. I like named parameters for any method that is likely to ever take
    more than one parameter.

TMTOWTDI. I prefer to have the "ordinary" case be as simple as possible, and require parameters only when their use is required. Simplicity is paramount, in my mind, so that if the only only you _need_ parameters is to specify something out of the ordinary, you shouldn't _require_ parameters for the simple case. A prototype of ($%) is very common, I believe, and completely appropriate for this sort of application.

Remember, you and I and everyone on this list have absolutely no problem with named parameters; a new Perl programmer is not going to understand the interface. CGI is a example of something that works equally well for new and expert users (if you don't think it is a monolithic monster ;~).

 b. It's way too magical and could cause very weird effects.  A simply
    typo could cause the extended parsing to be loaded, which would be
    very surprising for end users.

Like that ever happens! ;~)

 c. It would require DateTime.pm to know about all possible parsing
    extensions.  (Ok, a registration scheme could get around this)

Not at all; it would require the programmer to specify any _additional_ parsing methods above and beyond what is default. We could set the default to be as simple as ISO only and require additional action on the part of the programmer to enable anything else. Go back to my example of an array of methods which were progressively more expensive to run.

4. Given the choice between adding more parameters or more methods, I
prefer to add more methods, which is why I dislike

  DateTime->new( mysql => $mysql_dt )

as opposed to

  DateTime->from_mysql_datetime( $mysql_dt )

I don't like the former mode any more than I like the latter. ;~) A profusion of nearly identical methods is, IMNSHO, even more prone to the typo problems you mentioned above. Especially if the methods are just going to be run_on_names which describe their actions, thus making sure the source code is littered with extra text for no good reason. I would argue that

DateTime->new($mysql_dt, parse => mySQL);

is much more readable and just as easy to program. Just because other OO languages make you go to somelengths to use polymorphic function calls, doesn't mean we need to limit Perl to their programming styles.

Just my 2 cents. I fully accept that you are the driver here and you will win the argument if it comes down to it.

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747