Conversation
…f FALSE if the needle was not found (BC break)
|
+1 for immutable version, but I don't think changing parent class is a good idea due to BC constraints, mostly because of typehints in userland and entirely different behavior... Rather properly deprecate DateTime in favor of new variant. |
|
Deprecate for new variant seems better to me. The point is that a lot of people just will change class name, so functionality that traces bottlenecks should be useful in new class. I am not sure about name, because |
Why? It sounds explicit and logic.
|
|
|
|
Well, that's issue for another repository :) |
|
What about something like that |
|
There is still #82 though - kill DateTime entirely. 😊 |
|
To kill DateTime is colossal BC break. |
|
Migration to different class is as well and helper methods would be kept in new helper class. |
|
__toString and jsonEncode is added value. (I dont need them, but BC…) |
|
Helper class for immutable DateTime factories can have name DateTimes, for cosistency with Arrays and Strings ;) |
8a9b344 to
a7f9308
Compare
|
What about name |
ba38669 to
bba41ff
Compare
|
The helper class for the added functionality (working with The loss of |
c4dc559 to
f6984a9
Compare
1765d9d to
17932ce
Compare
ad7c562 to
baa7cb7
Compare
5139bb3 to
a8ed180
Compare
4018aba to
c5b54d1
Compare
e673736 to
299a857
Compare
c168cad to
077dc71
Compare
I am looking for way how move from mutable to immutable DateTime.
From my point of view, mutable DateTime is something you never want (of couse I may be wrong). And switch from mutable to immutable is big BC break. On the other hand, I found way how to discover bottlenecks (like this one) where mutable and immutable behave differently and I can trigger error. So maybe the transition from one model to another would be possible.