Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Immutable DateTime [WIP] #133

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Immutable DateTime [WIP] #133

wants to merge 6 commits into from

Conversation

dg
Copy link
Member

@dg dg commented Feb 1, 2017

  • new feature? no
  • BC break? yes

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.

@Majkl578
Copy link
Contributor

Majkl578 commented Feb 1, 2017

+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.

@dg
Copy link
Member Author

dg commented Feb 1, 2017

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 Nette\Utils\DateTimeImmutable sounds terrible to me.

@TomasVotruba
Copy link

I am not sure about name, because Nette\Utils\DateTimeImmutable sounds terrible.

Why? It sounds explicit and logic.

  • DateTime => Nette\Utils\DateTime
  • DateTimeImmutable => Nette\Utils\DateTimeImmutable

@dg
Copy link
Member Author

dg commented Feb 1, 2017

\DateTimeImmutable sound terrible too :)

@TomasVotruba
Copy link

Well, that's issue for another repository :)

@michalhlavka
Copy link

michalhlavka commented Feb 1, 2017

What about something like that Nette\Utils\Immutable\DateTime, that also wrong, but something like this principle

@Majkl578
Copy link
Contributor

Majkl578 commented Feb 1, 2017

There is still #82 though - kill DateTime entirely. 😊

@dg
Copy link
Member Author

dg commented Feb 1, 2017

To kill DateTime is colossal BC break.

@Majkl578
Copy link
Contributor

Majkl578 commented Feb 1, 2017

Migration to different class is as well and helper methods would be kept in new helper class.
And honestly, what is the added value of extending (inheriting) PHP's DateTime(Immutable)? Adding some helper methods and making code less portable?

@dg
Copy link
Member Author

dg commented Feb 1, 2017

__toString and jsonEncode is added value.

(I dont need them, but BC…)

@dg
Copy link
Member Author

dg commented Feb 1, 2017

Helper class for immutable DateTime factories can have name DateTimes, for cosistency with Arrays and Strings ;)

@dg dg force-pushed the master branch 2 times, most recently from 8a9b344 to a7f9308 Compare February 1, 2017 23:53
@milo
Copy link
Member

milo commented Feb 2, 2017

What about name Timestamp?

@dg dg force-pushed the master branch 4 times, most recently from ba38669 to bba41ff Compare February 10, 2017 12:52
@pavelkouril
Copy link
Contributor

The helper class for the added functionality (working with DateTimeInterface) and just deprecating Nette DateTime is IMHO the best option.

The loss of __toString kinda sucks, but other aspects outweight the loss of it.

@dg dg force-pushed the master branch 3 times, most recently from c4dc559 to f6984a9 Compare July 21, 2017 18:48
@dg dg force-pushed the master branch 12 times, most recently from 6733224 to 5de10a1 Compare June 18, 2024 21:22
@dg dg force-pushed the master branch 16 times, most recently from a846fab to 736c567 Compare August 7, 2024 16:18
@dg dg force-pushed the master branch 2 times, most recently from cd9170e to 2b48b24 Compare December 12, 2024 10:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants