Dave Rolsky wrote:
I'm not sure what you mean. It's much quicker for operations that occur before the rebless. If you were to keep using that object for further operations, the speed increase given from calling one "diet" method would fade into background noise.
True. I expected a quicker degeneration, but was quite surprised. The point of DateTime::Diet was to be able to quickly create lots of DateTime-able objects.
The implementation means that they transparently convert to being full DateTime object whenever you need to do anything with them.
But this might be useful for cases where people have to create lots of objects, they don't care about time zones, and they rarely have to use the "advanced" DT.pm methods (math, time zones, etc).
Almost agree. It's a subtle difference to me between creating lots of object and doing things with them. When I link to a database, the link turns dates into object. However I don't need to do anything with most of them. For example, I don't need to compare them, as I'd have done that in SQL.
From there, I can still access the objects as if they were full blown DateTime objects because they will become such objects when they need to.
I suspect people would want to be able to use this in conjunction with a parser like DT::Format::MySQL or something, where they know the data in the DB represents real datetimes.
Exactly. My thought is that this sort of module is ideally suited here. We know the data is a real datetime so the validation isn't needed. We're (potentially) creating lots of objects and so the time/memory overhead saving is useful.
Geoffrey, if you're reading this, I'd love your comments on how useful this would be in your case.
Of course at the moment I'm just handling the simplest of setters and getters, but there's no reason why we couldn't include some other things like strptime, ymd, datetime etc. (Strptime would be interesting as it would need to failover to DateTime on some patterns)
The main thing would be not to increase the amount of time it takes to create the object, so there'd be no math (that relies on month lengths, leap years, DST etc). The most data this will hold is that which can be passed to DateTime->new().
Cheers! Rick Measham
