develooper Front page | perl.datetime | Postings from January 2003

Re: Parser Interface (Was Re: Picking up the ball)

Thread Previous | Thread Next
Dave Rolsky
January 14, 2003 09:55
Re: Parser Interface (Was Re: Picking up the ball)
Message ID:
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:

> >> Looking at the two alternatives, does the second really seem clearer?
> >>
> >>    use DateTime;
> >>    my $dt = DateTime->new( 'MySQL' => $mysql_dt );
> >>    print $dt->to_string( 'MySQL' );
> >>
> >>    use DateTime;
> >>    use DateTime::Parse::MySQL;
> >>    my $dt = DateTime->from_mysql_datetime( $mysql_dt );
> >>    print $dt->to_mysql_string();
> >
> > Um, yeah, the second is _much_ clearer.
> Hmm... Really? To me, the first seems much clearer.
> If this framework grows in the future, won't we end up with dozens of
> parser/formatter modules all stuffing methods into the base class?

Only if you load all of them.  Why would you do that?

> And if someone wants to build a separate implementation of the DateTime
> interface, like the TAI64 code, how will they be able to integrate with
> those parsing/formatting modules, short of blindly making their code a
> subclass of the primary implementation?

Yes, other implementations will blindly inherit from the base class.
That's ok.  For example, it'll want to inherit things like strftime and so

> If there's a public consensus that most people prefer stuffing methods
> into the base package rather than having a gateway interface that
> dynamically dispatches calls to other classes, I'll drop the issue, but
> it seems to me like a significant mistake.

I haven't decided this is the way to go, but I don't like the "more params
to new()" way at all.

> > What if a specific parser needs _two_ params?
> Presumably it could accept an array-ref, or grab a list of arguments.

No, my point was what if I do this:

  my $dt = DateTime->new
               ( extended_parse => "Vendredi, la semaine prochaine",
                                 # Thursday, next week in French (I hope ;)
                 language => 'French' );

The module that implements extended parsing will need to get at the
language parameter.  How will know to pass that along?  I
guess it could just pass everything it got, though.

> > Your first option is not on the table.
> Er, why not?

Cause I don't like it.  Some decisions have to be made by fiat, because as
we can see there are lots of people with different, conflicting, valid
opinions.  But in the end, we need one consistent API.  Since I'm in
charge (FWIW) that means I'm the one who gets to decide what goes in and
what doesn't.

> > The options on the table are: [...] or
> >   use DateTime;
> >   use DateTime::Parse::MySQL;
> >   my $dt = DateTime::Parse::MySQL->new_datetime( $mysql_dt );
> >   print DateTime::Parse::MySQL->mysql_datetime( $dt );
> That's a straw man -- AFAIK, nobody's suggesting this kind of API.

I was, actually.

> Decorators are a dynamic composition of objects, nestable such that you
> can stick one decorator in front of another, and each one is provided
> by a different class and so has its own namespace and inheritance tree.

Thanks, I know what a decorator is in GoF-speak ;)

This achieves exactly the same thing as a decorator, without a whole stack
of objects needed.


House Absolute Consulting

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About