Re: DateTime::Lite

> Lite may pass the set of tests you extracted, but what about compatability
> with DateTime extensions like ::Set? I contend that the best way to tackle
> something like this and yield a more broadly useful "Lite" kit would be
> to get DateTime to use AutoSplit and/or subclass DateTime to override the
> chubbier bits. In my usage of DateTime, loading has never been the issue,
> but rather things like parameter validation and lack of memoization
> (friendliness).

um, wait wait.
Okay, so I don't want, nor intend to claim Datetime::Lite to be 100% API
  compatible with DateTime. I don't intend for DateTime::*** modules to
use DateTime::Lite. This is for people who use the minimal aspects of
DateTime, which is mainly to grab a date, do some calculation, and maybe
print them out.

But at the same time, I don't want Time::Piece (even if it was pure
perl), but something that resembles DateTime, because

1. I want something that can  (relatively) easily be replaced back to
DateTime later.
2. I want something that is as "full-featured" as DateTime, so  my
audience don't start saying things like "Well, using modules give you
performance penalty, so let's /not/ use them at all!" or "Perl sucks,
let's use XXXX" because of petty performance problems.



okay, so I'm starting to suspect that I didn't define my audience, and
that's causing people to go "WTF, another bad clone?". Perhaps that's
what's Jaldhar is asking elsewhere in this thread.

--d