Still mutable about carbon

[amitailanciano]

+1, would love to see this -- remembering to chain ->copy() all the time is pretty annoying/frustrating

[marijn]

Anything that modifies the internal state should return a new instance.

<?php
public function modify($mod)
{
    $instance = clone $this;

    $instance->modify($mod);

    return $instance;
}

[briannesbitt]

Correct. There are no immediate plans to change this. However, I don't think it would take too much to create a subclass that used a copy on write strategy for mutating function calls.

[marijn]

I agree with @beberlei, the fact that DateTime is mutable is very annoying.

Please consider making this immutable.

[briannesbitt]

So would a copy on write implementation fit the bill? Thoughts?

[briannesbitt]

Yes, I get that.. hence the copy on write implementation comment. Is that what you guys are looking for?

[rjkip]

I agree, this behaviour is annoying, but wouldn't it break BC? What about a copy() method to allow chaining?

<?php

# Hmm, no pun intended here...
$carbon->copy()->modify("midnight");

Perhaps the copy on write implementation should wait for a BC breaking v2.0.0?

[rjkip]

Meh, never mind. It already exists... :x

[briannesbitt]

No further action here... going to close it for now.

[falk]

Someone tried to fix it in php 5.5: http://www.php.net/manual/en/class.datetimeimmutable.php , but not without issues http://comments.gmane.org/gmane.comp.php.devel/78803

[briannesbitt]

Its not high on my list right now. As I have said though, I think a copy on write implementation would be pretty quick.

[beberlei]

@falk the issues of the mailing list were completly fixed, 5.5 has an immutable date time that works flawlessly.

[tabennett]

+1, this just bit us today at work. Side-effects suck and make Carbon more difficult to use as a value object.