On Tue, 28 Jan 2003, John Peacock wrote:
> Tell you what; I'll write an implementation of my way (probably in XS) and we'll
> compare. I think you're mistaken; your storage methods requires conversion for
> all nontrivial operations (e.g. $dt->year), whereas mine only needs a conversion
> when changing bases (e.g. $dt->eastern_orthodox_easter). The only issue I need
> to deal with is determining which sub's compromise the actual implementation and
> which are producing values derivable from those subs. Going forward, it would
> be a very good idea to restructure the code so that this is obvious. I would
> even suggest going ahead and pulling all of the internals code out of the base
> module and create a default implementation module.
Well, an XS implementation is quite likely to beat pure Perl, even if you
used RD days as well.
But I would certainly welcome an XS implementation of the DateTime API.
In fact, having such a thing is a big goal of mine. As long as it can
produce Rata Die days on command, it's all good.
And yes, the code can definitely be cleaned up with regards to what needs
access to internal representation and what doesn't. In fact, we should
probably start using a _rata_die method internally to avoid relying on
$self->{rd_days} so a subclass can inherit all the component methods from
the parent.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
