Skip Menu |

This queue is for tickets about the DateTime-Format-Builder CPAN distribution.

Report information
The Basics
Id: 77223
Status: resolved
Priority: 0/
Queue: DateTime-Format-Builder

People
Owner: Nobody in particular
Requestors: ALUCAS [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: DateTime implementation is hardcoded
Given that this module is intended to be used as a base for format parsers in the DateTime family, it would be a nice feature if the DateTime class to use was not hardcoded, and was an attribute or something similarly configurable / overridable. This would be very useful for situations when using a DateTime subclass or non-standard DateTime object with the same interface / constructor signature. What do you think?
Subject: Re: [rt.cpan.org #77223] DateTime implementation is hardcoded
Date: Tue, 15 May 2012 11:52:46 -0500 (CDT)
To: Anthony J Lucas via RT <bug-DateTime-Format-Builder [...] rt.cpan.org>
From: Dave Rolsky <autarch [...] urth.org>
On Tue, 15 May 2012, Anthony J Lucas via RT wrote: Show quoted text
> Given that this module is intended to be used as a base for format parsers in the DateTime > family, it would be a nice feature if the DateTime class to use was not hardcoded, and was an > attribute or something similarly configurable / overridable. > > This would be very useful for situations when using a DateTime subclass or non-standard > DateTime object with the same interface / constructor signature. > > What do you think?
I agree. This is a general problem with the DateTime ecosystem. Many modules assume they should call DateTime->new when it'd be nice to make this a parameter. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/
On Tue May 15 12:52:55 2012, autarch@urth.org wrote: Show quoted text
> On Tue, 15 May 2012, Anthony J Lucas via RT wrote: >
> > Given that this module is intended to be used as a base for format
> parsers in the DateTime
> > family, it would be a nice feature if the DateTime class to use was
> not hardcoded, and was an
> > attribute or something similarly configurable / overridable. > > > > This would be very useful for situations when using a DateTime
> subclass or non-standard
> > DateTime object with the same interface / constructor signature. > > > > What do you think?
> > I agree. This is a general problem with the DateTime ecosystem. Many > modules assume they should call DateTime->new when it'd be nice to > make > this a parameter. > > > -dave > >
/*========================================================= === Show quoted text
> http://VegGuide.org http://blog.urth.org > Your guide to all that's veg House Absolute(ly Pointless) >
========================================================== ==*/ I've definitely noticed the trend. I was just in the middle of going through all of the modules I consider important to the DateTime family. If I wrote a patch for this, would it be accepted? Or did you already have something in mind? Regards, Anthony L
Subject: Re: [rt.cpan.org #77223] DateTime implementation is hardcoded
Date: Tue, 15 May 2012 13:39:55 -0500 (CDT)
To: Anthony J Lucas via RT <bug-DateTime-Format-Builder [...] rt.cpan.org>
From: Dave Rolsky <autarch [...] urth.org>
On Tue, 15 May 2012, Anthony J Lucas via RT wrote: Show quoted text
> If I wrote a patch for this, would it be accepted? Or did you already have something in mind?
I don't have anything in mind, but however this works, I'd want every similar module to work in the same way. It probably makes sense to make this a constructor parameter for parsers, something like "datetime_class", and have it default to DateTime. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/