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.
Hmm... Really? To me, the first seems much 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.
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.
I don't see the similarity to the decorator pattern.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!
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.
http://web.media.mit.edu/~tpminka/patterns/Decorator.html
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".
-Simon
