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

Front page | perl.datetime | Postings from January 2003

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

Thread Previous | Thread Next

From:

Matthew Simon Cavalletto

Date:

January 14, 2003 11:21

Subject:

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

Message ID:

5123AEE8-27F5-11D7-935D-003065AFEA5E@cavalletto.org

On Tuesday, January 14, 2003, at 12:55  PM, Dave Rolsky wrote:

>>>>    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.
>>
>> [...] 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 on.

My suggestion would be that strftime also be placed in an external 
module.

   package DateTime::Format::strtime;

   sub string_to_rdsec { ... } # strptime

   sub rdsec_to_string { ... } # strftime

This same interface could be used polymorphically for any date 
parsing/stringification library, and can be used directly by other 
modules, in addition to via a DateTime object.

Users could be isolated from this behind the current interface:

   package DateTime;
   require DateTime::Format::strtime;

   sub strptime {
     (shift)->new( DateTime::Format::strtime->string_to_rdsec( @_ ) )
   }

   sub strftime {
     DateTime::Format::strtime->rdsec_to_string( (shift)->as_rdsec, @_ )
   }

Modules like Date::Discordian or Date::Maya, which have no internal 
storage format and only exist to convert to and from other calendar 
formats, could easily be refactored to follow this interface.

   my $dt = DateTime->new( .... );

   print $dt->to_string( strftime => $fmt );
   # Calls DateTime::Format::strtime::rdsec_to_string($rd, $sec, $fmt)

   print $dt->to_string( 'Discordian' );
   # Calls DateTime::Format::Discordian::rdsec_to_string($rd, $sec)

>>> Your first option is not on the table.
>>
>> Er, why not?
>
> Cause I don't like it.

Ouch.

> 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.

I agree that a certain amount of that approach is needed, but taken to 
extremes this may doom the project to being just another contender in 
the date/time space, rather than the open framework everyone 
standardizes on and interoperates with.

>>> The options on the table are: [...]
>>
>> That's a straw man -- AFAIK, nobody's suggesting this kind of API.
>
> I was, actually.

OK, sorry for the confusion.

>> 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.

Regardless, the point I've been trying to make is that we don't want 
Decorators.

We want something more like Strategies (ie, given several similar 
algorithms, rather than having a bunch of different methods or a big 
case statement, put each in its own class and call them as needed):

   http://c2.com/cgi/wiki?StrategyPattern

On Tuesday, January 14, 2003, at 01:07  PM, Dave Rolsky wrote:
> I'm very strongly opposed to something that just passes random strings 
> into new() and then loads the module on demand.

They're not random strings, they're class names; passing classes as 
arguments is common OO framework practice.

We could turn off on-demand module loading, or default to off unless 
you explicitly request it, if that part seems undesirable.

-Simon

Thread Previous | Thread Next