On Thu, Jul 21, 2005 at 01:54:30PM +1000, Rick Measham wrote:
I want to wrap this up and release so there's 24 hours to finalise the
name. Here's the names I like thus far:
DateTime::LazyInit (from John Siracusa)
DateTime::Mock (from Joshua Hoblitt)
DateTime::Diet (original
Quoting Rick Measham [EMAIL PROTECTED]:
Joshua Hoblitt wrote:
What about DateTime::Mock? Since that would make it clear that this
isn't /really/ a DT object.
Thanks Joshua,
I want to wrap this up and release so there's 24 hours to finalise the
name. Here's the names I like thus far:
On 21 Jul 2005, at 15:51, [EMAIL PROTECTED] wrote:
Quoting Rick Measham [EMAIL PROTECTED]:
Joshua Hoblitt wrote:
What about DateTime::Mock? Since that would make it clear that this
isn't /really/ a DT object.
Thanks Joshua,
I want to wrap this up and release so there's 24 hours to
DateTime::LazyInit (from John Siracusa) has received the most votes by
far, so I'll go with it. As one respondant put it, it has 'plain spokenness'
DateTime::Diet, the other name to recieve some votes, made me think of
'DateTime::Lite', and it isn't -- it's full-blown DateTime, just not
Joshua Hoblitt wrote:
What about DateTime::Mock? Since that would make it clear that this
isn't /really/ a DT object.
Thanks Joshua,
I want to wrap this up and release so there's 24 hours to finalise the
name. Here's the names I like thus far:
DateTime::LazyInit (from John Siracusa)
On Thu, 21 Jul 2005, Rick Measham wrote:
Joshua Hoblitt wrote:
What about DateTime::Mock? Since that would make it clear that this
isn't /really/ a DT object.
Thanks Joshua,
I want to wrap this up and release so there's 24 hours to finalise the name.
Here's the names I like thus far:
Dave Rolsky wrote:
It has a pretty different API, in that it's new() constructor accepts
anything without validation.
I suppose it could check for extra args and call DateTime::Fat-new() if
needed.
Can we split the existing new() into validation vs. object creation and share it
between the
On Thu, 7 Jul 2005, Rick Measham wrote:
Dave Rolsky wrote:
It has a pretty different API, in that it's new() constructor accepts
anything without validation.
I suppose it could check for extra args and call DateTime::Fat-new() if
needed.
I think that'd be a possibility, but it'd have to
On 7/7/05 12:12 AM, Rick Measham wrote:
Dave Rolsky wrote:
DateTime::Shim
DateTime::Trampoline
DateTime::ThinShim
DateTime::Proxy
DateTime::Diet - not awful but a little cute, methinks ;)
Of the above, I still like DT:Diet.
If you want something less cute/more serious how
On Wed, 6 Jul 2005, Rick Measham wrote:
I've included the output of the attached script below. I was surprised to
note that even after the rebless was included in the tests, the Diet version
was still *much* quicker.
I'm not sure what you mean. It's much quicker for operations that occur
Geoffrey, if you're reading this, I'd love your comments on how useful
this would be in your case.
I am :)
ok, I haven't looked at the code yet, but from your explanations it sounds
attractive, especially in our situation. just like you, we don't
necessarily need data validation since the
Le 5 juil. 05 à 15:15, John Siracusa a écrit :
On 7/5/05 7:04 AM, Eric Cholet wrote:
A while ago we did some profiling of an app that uses DateTime
extensively and found out that most of the time is spent in
Params::Validate. I understand this is somewhat of a religious issue,
but in this
I've used this approach in Date::Set. It runs the same test suite of
DateTime::Event::ICal, in one third of the time.
- Flavio S. Glock
2005/7/6, Rick Measham [EMAIL PROTECTED]:
DateTime::Diet (attached) is a simple wrapper around DateTime that
handles simple new(), set() and get methods. If
On Wed, 6 Jul 2005, John Siracusa wrote:
If you're going for speed, there's more low-hanging fruit to be had.
Check
out my modifications in DateTime::Diet2 (attached).
Dave Rolsky wrote:
Yeah, I was thinking that we'd do something like this if we're going to
turn this into an officially
On Thu, 7 Jul 2005, Rick Measham wrote:
So .. would this module actually get used by anyone but me? If so I'll go
ahead and polish it off.
It sounded like people were interested. And maybe it's a if you build it
they will come thing ;)
Anyway, go for it and let's brainstorm on a better
Dave Rolsky wrote:
It sounded like people were interested. And maybe it's a if you build
it they will come thing ;)
Anyway, go for it and let's brainstorm on a better namespace. Here's
some thoughts:
At the risk of sounding flippant, why not rename the existing DateTime class to
On Wed, 6 Jul 2005, John Peacock wrote:
At the risk of sounding flippant, why not rename the existing DateTime
class to DateTime::Fat (or the less inflamatory DateTime::Base) and
put the proposed module in it's place as DateTime. If it is designed
well, everything should Just Work(TM) with
Dave Rolsky wrote:
DateTime::Shim
DateTime::Trampoline
DateTime::ThinShim
DateTime::Proxy
DateTime::Diet - not awful but a little cute, methinks ;)
Of the above, I still like DT:Diet.
If you want something less cute/more serious how about:
DateTime::FastConstructor
The others
Dave,
I agree about taking it with a grain of salt.
However,
a) it is true that DateTime is slow (compared to other alternatives), and
b) It's just not good that we give people excuse like this to
not to use DateTime or to make it look like DateTime is not up to par
So I think we
Le 4 juil. 05 à 19:47, Dave Rolsky a écrit :
Well, I'd take Sam's message with a grain of salt. I use it in
lots of projects, and I know it's being used by lots of other
people for lots of things. The idea that it's too slow is
bogus. It might be too slow/bulky if you're creating
On 7/5/05 7:04 AM, Eric Cholet wrote:
A while ago we did some profiling of an app that uses DateTime
extensively and found out that most of the time is spent in
Params::Validate. I understand this is somewhat of a religious issue,
but in this case it's a net loss for us: the params have been
21 matches
Mail list logo
