Remove incompatibility 8000 between \DateTime and \DateTimeImmutable #2678
Conversation
…ing \DateTimeInterface instead.
|
That cannot be done in this way since it will always create an instance of the mutable one when retrieving from database. #2450 solves that by adding new types for the immutable DateTime. |
|
@lcobucci The request is not intended to replace #2450 but rather make the lib usable with Currently you declare UPD: I meant 2.5 and Can you please reconsider it? I believe the change worth merging. |
|
Aha-ha 😄 I thought 2.6 is declared as stable (or at least compatible with 2.5). My bad ) But still I think it worth merging. |
|
The approach in this PR is wrong because a user may map a field as |
|
That's up to you guys. I don't see it as problem if user 'map a field as DateTime' and then 'have a DateTime in that field' even if a |
|
It was indeed decided, and @lcobucci decided to close this issue. I just
gave the backing thought.
Code amount is rarely a problem.
On 18 Mar 2017 14:37, "neomerx" <notifications@github.com> wrote:
That's up to you guys. I don't see it as problem if user 'map a field as
DateTime' and then 'have a DateTime in that field' even if a
\DateTimeImmutable was passed for storing to database.
The current code requires much more from input data than it actually needs.
Does it serve a purpose? You say it does however obviously not its own
purpose. Is it a way it should be designed? That's you to decide.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2678 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAJakHPRYKUBQSCz6Wk2VoPoN8GW6QxLks5rm94JgaJpZM4MgFoG>
.
|
... by using \DateTimeInterface instead.
Current implementation forbids using \DateTimeImmutable.
As only
formatmethod defined in\DateTimeInterfaceis really used it makes sense to use interface instead of the class.