On Sat, 11 Jan 2003, David Wheeler wrote: > > The first option has the advantage of greatly simplifying the > > internals. Once you calculate the julian day and seconds for an > > object, it just never changes. The disadvantage is that the API may > > seem odd to some folks. But we could still provide something like > > this: > > > > # same as $old_date but day of month is 5 > > my $new_date = $old_date->clone( day => 5 ); > > I think that this is an excellent idea. It's a good tradeoff between > flexibility and simplicity. People who just want setters will be able > to fake it like this: > > $date = $date->clone( day => 5 ); > > And I like the idea of static DateTime objects.
I think it's appealing for me in implementing it, and it's very logical, but is it practical? I'm not so sure about that. > > I favor exceptions myself, since I think if something is wrong, it > > should be considered catastrophically wrong, but I know this is a > > serious bone of contention. Aren't you glad I brought it up? > > I like exception, too, and you know that I'm a fan of Exception::Class. > However, it'd probably be ideal to allow users to determine how to deal > with these things, a la DBI's approach. That seems reasonable. Maybe default to throwing an object but allow a pluggable error handling subroutine reference? And maybe also a convenience option to turn off exceptions and just return undef/0 (like DBI's RaiseError). -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
