On Fri, 15 Feb 2013, Nikita Popov wrote: > for PHP 5.5 a new DateTimeImmutable class was introduced, which is a > variant of DateTime, which has methods working on a clone of the > original object. > > There was no RFC on this and some of the design decisions are a bit > uncleared to me, so I figured I'd write a mail: > > a) The DateTimeImmutable class extends the DateTime class. Why was > this done this way? Both classes are incompatible (as in the > inheritance violates LSP). E.g. if you hint against DateTime, then > passing in DateTimeImmutable will not work (as the behavior is > different). The same also applies the other way around (DateTime > extending DateTimeImmutable). Imho a mutable and an immutable variant > of a class can't reasonably extend from one another, so I'm not sure > why this was done.
It was mostly done so that methods and code accepting do not need signature changes. In many cases library code would accept a DateTime, call modify and return the changed object - not realizing that the original object was changed as well causes issues with calling code. By having DateTimeImmutable extend DateTime they can continue to pass them in, without having to change library code at all. > b) The DateTimeImmutable class is (method-wise) an exact copy of > DateTime. This makes for some rather weird method names for an > immutable object. E.g. there is DateTimeImmutable::modify, which to me > seems quite contradictory. There are also a lot of methods of the > DateTimeImmutable::setTime form, which also seems rather odd and > confusing (how can I set something on an immutable object?) It just returns the changed object instead of changing the object itself *and* returning the changed object (as DateTime does). cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
