FAQ
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

Search Discussions

  • Darren Duncan at Jan 16, 2015 at 12:39 am
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdatetime @
categoriesperl
postedDec 13, '14 at 12:13a
activeJan 16, '15 at 12:39a
posts2
users2
websitemetacpan.org...

2 users in discussion

Darren Duncan: 1 post Mark Grimes: 1 post

People

Translate

site design / logo © 2019 Grokbase