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

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

Thread Previous | Thread Next
Matthew Simon Cavalletto
January 14, 2003 00:46
Re: Parser Interface (Was Re: Picking up the ball)
Message ID:
On Monday, January 13, 2003, at 10:14  PM, Dave Rolsky wrote:

>  I _don't_ want to discuss implementation of this.  I want to talk 
> about the API!

Agreed; I'm making this argument specifically because I think the 
proposed API is clearer.

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

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?

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.

> And how is DateTime->new supposed to know about all the myriad 
> parameters that would exist with your suggestion anyway?  If it finds 
> an unknown parameter, should it call "DateTime::Parse->$param()"?

No, it would load a module named DateTime::Parse::$param, and then call 
a method on that class, eg DateTime::Parse::MySQL->parse_string().

> And its less error prone as well! If I mis-type 'MySQL' as 'Mysql' 
> then what is DateTime supposed to do?

If you mis-enter the name of a module, it would die with a message 
along the lines of "The $param format is unknown, and 
DateTime::Parse::$param can't be found in @INC; please check that 
you've written the format name correctly and that the associated module 
is installed on this host.";

> What if a specific parser needs _two_ params?

Presumably it could accept an array-ref, or grab a list of arguments.

> Your first option is not on the table.

Er, why not?

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

> Frankly, I think the first one is a lot easier to use and makes more
> sense.  It's the decorator pattern without the dispatching overhead!

I don't see the similarity to the decorator pattern.

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.

The proposed approach of having add-on modules stuff new methods into 
the core class's namespace lacks all of those qualities, and seems more 
  reminiscent to me of the "big ball of mud" pattern then it does of 
some kind of "optimized decorator".


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