That seems to explain the logic of having an immutable DateTime type (to avoid breaking backwards compatibility with the inherently mutable old DateTime) but doesn't explain the logic of then including a modify() method for such objects.
objects of the DateTimeImmutable class are immutable. All methods that modify the object will return a new copy.
While the naming is a bit unfortunate, this isn't different from other languages that have immutable types like Java String which also have methods that act on the string they are called on and return a new copy.
Like concat().
String foo = "foo";
String foobar = foo.concat("bar");
// foo is still set to "foo"
And with datetimeimmutable:
$date = new DateTimeImmutable();
$other_date = $date->modify('+ 3 days');
// $date still is today.
Python strings work the same. And all the ruby string methods not ending with a bang also work the same.
The reason why the method is called 'modify' in PHP is because the old DateTime (mutable edition™) method was also called 'modify' and the two should be more or less drop-in replacements.
Besides - what would you call a method that modifies a timestamp?
> The reason why the method is called 'modify' in PHP is because the old DateTime (mutable edition™) method was also called 'modify' and the two should be more or less drop-in replacements.
The old datetime's method modifies the object in place[-1], if you replace the old with the new it's not going to work anymore.
> Besides - what would you call a method that modifies a timestamp?
Replace[0]? withFieldValue[1]? add with a delta object, possibly relative[2]?
[-1] it also returns the object it was called on since 5.3.0, the method was introduced in 5.2.0
> The old datetime's method modifies the object in place[-1], if you replace the old with the new it's not going to work anymore.
Of course it would be impossible to make the APIs exactly the same, because the two classes have different behaviour. But shouldn't they at least strive to make the APIs as similar as possible?
The behaviour is not completely dissimilar. The only difference between the two methods is what is done with the result. In fact, every method in that class parallels one from the other class in exactly that way, and that behaviour is described clearly on the documentation page for the class:
> This class behaves the same as DateTime except it never modifies itself but returns a new object instead.
$date = new DateTime();
$other_date = $date->modify('+ 1 day');
// $date is now tomorrow
with the new thing:
$date = new DateTimeImmutable();
$other_date = $date->modify('+ 1 day');
// $date is still today
Then, yes, clone($date_time)->modify() is equivalent to calling modify() on a $date_time, but the problem starts when you pass DateTime instances into functions because you just can't know what the function is going to do to that date object.
This means that you have to be very defensive, constantly calling clone() or you'll have your dates altered behind your back from some library that's called by a library you're calling.
This is one of those things that seems hilarious only because you are ignorant of what's actually happening. Being proud of finding this funny is being proud of your own ignorance.
