[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-datetime
Subject:    Re: Feedback on DateTime related module
From:       Darren Duncan <darren () darrenduncan ! net>
Date:       2015-01-16 0:39:39
Message-ID: 54B85DCB.4060200 () darrenduncan ! net
[Download RAW message or body]

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
> mgrimes@cpan.org <mailto:mgrimes@cpan.org>
>

[prev in list] [next in list] [prev in thread] [next in thread]