On Tue, 2 Apr 2024, Bilge wrote: > On 02/04/2024 14:14, Derick Rethans wrote: > > > > On Sun, 31 Mar 2024, Bilge wrote: > > > > > About the PR: I sometimes find it would be useful to only update > > > part of the date. The PR makes all parameters to > > > DateTime(Immutable)::setDate > > > <https://www.php.net/manual/en/datetimeimmutable.setdate.php> > > > optional in a backwards-compatible manner such that we can elect > > > to update only the day, month, year or any combination of the > > > three (thanks, in part, to named parameters). Without this > > > modification, we must always specify all of the day, month and > > > year parameters to change the date. > > As I mentioned to you in Room 11, I am not in favour of adhoc API > > changes to Date/Time classes. It has now been nearly 18 years since > > they were originally introduced, and they indeed could do with an > > overhaul. > > > > I have been colllecting ideas in > > https://docs.google.com/document/d/1pxPSRbfATKE4TFWw72K3p7ir-02YQbTf3S3SIxOKWsk/edit#heading=h.2jol7kfhmijb > > > > Having different/better modifiers would also be a good thing to talk > > about, albeit perhaps on the four mentioned new classes, instead of > > adding them to the already existing DateTime and DateTimeImmutable > > classes. > > > > In any case, just allowing setDate to be able to just modify the > > month is going to introduce confusion, as this will be counter > > intuitive: > > > > $dt = new DateTimeImmutable("2024-03-31"); > > $newDt = $dt->setDate( month: 2 ); > > > > It is now representing 2024-03-02. > > > > This might be the right answer, but it might also be that the > > developer just cared about the month part (and not the > > day-of-month), in which case this is a WTF moment. > > > > Picking mofication APIs is not as trivial as it seems, and I would > > like to do it *right*. > > > > Feel free to add comments and wishes to the google doc document. In > > the near future, I will be writing up an RFC from this. > > Thanks for your reply! > > Indeed, as per your code snippet, this is a WTF moment I had not accounted for > and confirm the same result with my patch applied. Generally, my expectation > here would be the month *must* be set to 2, so if the day portion will be > invalidated by that change, we should either throw an exception or implicitly > coerce it into range, i.e. (new DateTime("2024-03-31"))->setDate(month: 2); == > 2024-02-29.
We can't do that, as it will be inconsistent with: <?php $d = new DateTimeImmutable("2024-01-31"); $d->modify("+1 month") // (also 2024-03-02) > However, I suppose this is not the conversation we're having as > you do not wish to change this API at all, which I respect. I think what you're actually after here, is a "YearMonth" type, which doesn't concern itself with the day-of-month at all. Setting just the month should perhaps just reset the day-of-month to 1 instead. ANd setting just the year would result in January 1st, as well. > Regarding your brainstorm document, I can't understand much of it in its > current state, and as I am not a subject matter expert, I think you will > receive much better feedback from others. It isn't particularly organised yet, and... I also haven't made sense of all of it yet. > In particular, I cannot glean which four classes you are referring to > in that document. Yet what I do find interesting is the notion of > adding setters to DateTimeImmutable. For my particular > use-case—producing a collection of dates incrementing by year in a > Twig template—a trivial year setter would do just fine, with the > significant caveat that it must implement fluent interface, because I > need to call it in an expression context (returning a value), not a > statement context (executing a void function separately). Not that > Twig cannot execute statements, but it just becomes more verbose, > cumbersome and less template-like. > > If you were happy for me to add getters and fluent setters for year, > I'd be happy to work on that PR, but for month we're back to the same > problem outlined in the opening paragraph (and I suppose the same > problem occasionally applies to year, if the day happens to be set to > the leap day). Otherwise, I'll be happy to read over your RFC when > it's ready. Feel free to add your suggestion (anywhere) in the document, preferrably at the bottom :-) I can envision that we'll have some actual setters and getters, beyond just add, sub, and modify (which is really powerful). But what is important to understand is rather *why* a specific method is useful, and perhaps even more important is what you're actual goal is. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social