> 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
