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. Thank you. 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 Moonpig introduces. 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 input! Best regards, Mark [email protected] <mailto:[email protected]>
