Hi!
> The problem with the argument that "everybody 'typehints' DateTime; we
> should inherit from it so that the code will run when the pass it a
> DateTimeImmutable" is that it assumes that everybody who typehints
> DateTime uses DateTime in a manner compatible with DateTimeImmutable. I
> don't believe that no one relies on DateTime method's side effects -- I
> certainly do.
We can not make sense of the problem if we keep talking in terms of
"everybody is doing this or that". There's nothing that "everybody" is
doing - there are tons of different usage patterns, some of them common,
some incompatible. We need to look on what is more probable - that
people use DateTime as hint for operations that do not modify the
incoming object or that they do modify it and also would put
DateTimeImmutable in this code.
So on one side we have existing code that would not accept
DateTimeImmutable without extensive modification, unless we create the
inheritance, on the other side we have some code that modifies DateTime
and should be protected from passing DateTimeImmutable - but there's no
such code yet since nobody passes DateTimeImmutable anywhere yet, so we
don't make any problem for existing code.
My personal opinion is that having the first covered covers more cases
than the second, since it saves more boilerplate code.
> The argument is that people are using DateTime as if it were immutable and
> you can now fix this wrong code by passing a DateTimeImmutable instead? I
> find it highly unlikely.
I find it highly likely that majoirty of DateTime users don't care if
it's mutable or not since they either don't change it (most frequent use
case) or use something like $foo = $bar->modify("+1 day"); and never
rely on the fact that $bar was modified. Of course, I have no data about
how many but I find it highly likely that many users simply don't care
about the difference.
> IMO, the classes should not be part of the same hierarchy. If it doesn't
This means hinting for DateTime would be useless for common
(non-modifying) use cases and there's no recourse to do anything else
since there's no common ground. The name DateTimeImmutable kind of
implies it is the same as DateTime only not mutable, but in fact writing
code that could accept them both
> Even if most people DO use DateTime in a compatible way, this is a very
> myopic way to advance the language or handle a transition. If the
> DateTimeImmutable interface is superior, people will move to it. If it's
> important for functions to accept both (I don't think it is), a common
> superclass with weaker guarantees can be extracted.
That would create javaesque constructs of classes and interfaces that do
nothing useful but exist merely so that there would be nice hierarchies,
and people would have to learn all that to use them, which makes it
significantly harder to use the language.
--
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
