Sorry I didn't see and respond to this a month ago.
As feedback ...
I propose that DateTime itself would benefit from some updates concerning
immutability support, in the form of a pair of new features that reflect
practices followed by Perl core releases.
The first feature would be to provide additional syntax where required so that
it is possible to use DateTime in a completely non-mutating fashion. For any
method/sub that currently mutates the value of a DateTime object, a non-mutating
alternative that just returns a new DateTime object would be added if it doesn't
already exist. Where this alternative is a new method/sub, it would have the
same name as the old one but with some terse suffix or prefix, eg "_r". Where
the alternative is a new parameter to the existing method/sub to change its
behavior, it should be cleanly self-documenting. I suggest that adding new
_r/etc subs is a more elegant solution though.
For some prior art, see Perl 5.14.0's introduction of the /r modifier to s///
which causes it to be non-destructive and return the new string.
The second feature I propose would be a new Perl warning that DateTime mutating
methods would issue when called. This warning would only occur when some new
flag is set by the user in an appropriate place, eg it could be a package
variable or a DateTime object property or both, whatever is good practice. The
warning would be explicitly opt-in for users; users can also opt for it to be a
fatal. The warning would tell the user that a DateTime mutator was called and
to avoid this behavior they can use the non-mutating alternative.
If DateTime were to implement these changes itself, that would be a large boon
to users, and it should be completely backwards-compatible. Other third-party
solutions that do other behavior changes can continue to coexist with this too.
What do you think?
-- Darren Duncan
On 2014-12-12 4:13 PM, Mark Grimes wrote:
Dave et al,
First off, thank you for your work on DateTime. I'm sure you have heard this
many times, but I use it in pretty much every project and really appreciate it.
On to the meat...
I've begun using a module that is DateTime subclass, and I'm considering
releasing it. I was hoping to get some feedback from the DateTime team before
going too far down the road.
The module addresses an issue that I have repeatedly run into when using
DateTime: mutability. DateTime works as advertised, and the bugs introduced are
100% due to my mistakes, but I don't think I'm alone in introducing bugs by
inadvertently modifying a DateTime object.
I know there are a couple of modules that attempt to address this in some way.
I've used DateTime::Moonpig before, but it never quite fits the bill. I still
want to be able to call the set and truncate methods, I just don't want the
original DateTime object to be modified. I also don't need the other changes
So, I'm considering releasing "DateTimeX::Immutable" (name open for discussion).
It overrides most of the same methods that DateTime::Moonpig does, but instead
of croaking, it clones the DateTime object then returns the result. It is
actually implemented it as a role (using Role::Tiny) so it can be composed into
other custom subclasses. It is a very simple module with minimal code (something
I've generally found to be good thing).
An initial version is available on github
(https://github.com/mvgrimes/perl-datetimex-immutable). I would be happy to
contribute the code to the DateTime project there is interest. Thanks for your