New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Still mutable #2

Closed
beberlei opened this Issue Sep 12, 2012 · 13 comments

Comments

7 participants
@beberlei

beberlei commented Sep 12, 2012

The most annoying thing about PHP DateTime is that they objects are mutable. It seems this is not changed in Carbon?

@briannesbitt

This comment has been minimized.

Show comment
Hide comment
@briannesbitt

briannesbitt Sep 12, 2012

Owner

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.

Owner

briannesbitt commented Sep 12, 2012

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

This comment has been minimized.

Show comment
Hide comment
@marijn

marijn Sep 12, 2012

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

Please consider making this immutable.

marijn commented Sep 12, 2012

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

Please consider making this immutable.

@briannesbitt

This comment has been minimized.

Show comment
Hide comment
@briannesbitt

briannesbitt Sep 17, 2012

Owner

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

Owner

briannesbitt commented Sep 17, 2012

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

@marijn

This comment has been minimized.

Show comment
Hide comment
@marijn

marijn Sep 17, 2012

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

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

    $instance->modify($mod);

    return $instance;
}

marijn commented Sep 17, 2012

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

This comment has been minimized.

Show comment
Hide comment
@briannesbitt

briannesbitt Sep 17, 2012

Owner

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

Owner

briannesbitt commented Sep 17, 2012

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

@rjkip

This comment has been minimized.

Show comment
Hide comment
@rjkip

rjkip Nov 23, 2012

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 commented Nov 23, 2012

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

This comment has been minimized.

Show comment
Hide comment
@rjkip

rjkip Nov 23, 2012

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

rjkip commented Nov 23, 2012

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

@briannesbitt

This comment has been minimized.

Show comment
Hide comment
@briannesbitt

briannesbitt Aug 7, 2013

Owner

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

Owner

briannesbitt commented Aug 7, 2013

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

@falk

This comment has been minimized.

Show comment
Hide comment
@falk

falk commented Aug 11, 2013

@briannesbitt

This comment has been minimized.

Show comment
Hide comment
@briannesbitt

briannesbitt Aug 11, 2013

Owner

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

Owner

briannesbitt commented Aug 11, 2013

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

This comment has been minimized.

Show comment
Hide comment
@beberlei

beberlei Aug 11, 2013

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

beberlei commented Aug 11, 2013

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

briannesbitt pushed a commit that referenced this issue Jun 26, 2016

Merge pull request #2 from lucasmichot/lndj-master-2
Fix Zh translation and add tests
@amitailanciano

This comment has been minimized.

Show comment
Hide comment
@amitailanciano

amitailanciano Sep 15, 2016

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

amitailanciano commented Sep 15, 2016

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

@tabennett

This comment has been minimized.

Show comment
Hide comment
@tabennett

tabennett Oct 23, 2017

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

tabennett commented Oct 23, 2017

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

Ovsyanka pushed a commit to Ovsyanka/Carbon that referenced this issue Jan 11, 2018

Merge pull request #2 from CarbonDate/risky-tests
Update risky & skipped tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment