[ hopefully this will move to the new thread I just started ... ]
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
> 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)
Hmmm, this isn't a bad idea. But how is it much better than:
my $disc = DateTime::Calendar::Discordian->new( ... );
print DateTime->new( object => $disc )->strftime( ... );
??
> >> Er, why not?
> >
> > Cause I don't like it.
>
> Ouch.
Actually, I just posted a message explaining _why_ 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.
>
> 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.
I agree. I'm trying to be relatively benevolent dictator, and I hope if I
really piss someone off (or I'm about to) that I get called on it.
> 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):
For formatting, strategies really don't make sense. Formatting isn't a
question of different algorithms, it's a question of having functionality
A and/or B.
For parsing, the strategy pattern _does_ make sense, but I think
decorators work as well. And I'm strongly inclined to treat parsing and
formatting as the "same" thing (well, really, the opposite thing) because
it seems likely that implementors of parsing for format X will also want
to implement output in format X, and it'll be easier to put this in a
single module if the implementation is done in the same manner.
> 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.
On demand loading is out (see my recent post).
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
