Hey, would it be possible for DateTime and DateTimeImmutable to not extend each other at all and be two seperate classes?
greetings, Benjamin On Sun, Feb 17, 2013 at 12:30 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote: > Hi! > > > a) The DateTimeImmutable class extends the DateTime class. Why was this > > done this way? Both classes are incompatible (as in the inheritance > > They're not really "incompatible". Functions that do not modify dates > would work just fine. So it's "not 100% compatible", which is not the > same as incompatible. Of course, we could instead create > DateTimeBaseAbstractClass, but IMHO rewriting all your code to support > it wouldn't be worth the trouble for 99.9% of the code, so what would > end up happening that nobody could use DateTimeImmutable with any > existing code that expects DateTime. I personally don't see much point > in DateTimeImmutable anyway (immutable data structures are very > important for concurrent programs but for PHP I don't see much benefit) > but if people need it, fine. But ask yourself a question - do you really > want to rewrite every library that accepts DateTime as an argument in > order to use DateTimeImmutable? > > > 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?) > > I don't see how it's so hard to grasp - it sets time and returns the > modified object. I can't believe you genuinely don't understand how it > works. I have a feeling this "confusing" argument in getting somewhat > stale: PHP users - especially those that want to use specially designed > classes that are useable only in context of design of non-trivial > complexity - have sufficient brain capacity to understand what setTime > could do. And if they absolutely can't, they can to the unthinkable - > read the manual. > So I can see the LSP argument - but "confusing" argument really doesn't > seem to apply here. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
