Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122909
Date: Wed, 3 Apr 2024 15:43:53 +0100 (BST)
To: Bilge <bilge@scriptfusion.com>
cc: internals@lists.php.net
Subject: Re: [PHP-DEV] First time contributor (DateTime::setDate PR)
In-Reply-To: <98aafc64-4b78-4948-b2ba-6a36f22b9b67@scriptfusion.com>
Message-ID: <d698cf4e-2b12-0e00-b321-8f342008fc8b@php.net>
References: <31f7de10-a2dd-489e-bc2f-66987dc832aa@scriptfusion.com> <d0294f5f-9e71-4a3c-10b4-1a5da4de4060@php.net> <98aafc64-4b78-4948-b2ba-6a36f22b9b67@scriptfusion.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1258066982-1712155433=:14553"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1258066982-1712155433=:14553
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 2 Apr 2024, Bilge wrote:

> On 02/04/2024 14:14, Derick Rethans wrote:
> >=20
> > On Sun, 31 Mar 2024, Bilge wrote:
> >=20
> > > About the PR: I sometimes find it would be useful to only update=20
> > > part of the date. The PR makes all parameters to=20
> > > DateTime(Immutable)::setDate=20
> > > <https://www.php.net/manual/en/datetimeimmutable.setdate.php>=20
> > > optional in a backwards-compatible manner such that we can elect=20
> > > to update only the day, month, year or any combination of the=20
> > > three (thanks, in part, to named parameters). Without this=20
> > > modification, we must always specify all of the day, month and=20
> > > year parameters to change the date.
> > As I mentioned to you in Room 11, I am not in favour of adhoc API=20
> > changes to Date/Time classes. It has now been nearly 18 years since=20
> > they were originally introduced, and they indeed could do with an=20
> > overhaul.
> >=20
> > I have been colllecting ideas in=20
> > https://docs.google.com/document/d/1pxPSRbfATKE4TFWw72K3p7ir-02YQbTf3S3=
SIxOKWsk/edit#heading=3Dh.2jol7kfhmijb
> >=20
> > Having different/better modifiers would also be a good thing to talk=20
> > about, albeit perhaps on the four mentioned new classes, instead of=20
> > adding them to the already existing DateTime and DateTimeImmutable=20
> > classes.
> >=20
> > In any case, just allowing setDate to be able to just modify the=20
> > month is going to introduce confusion, as this will be counter=20
> > intuitive:
> >=20
> > $dt =3D new DateTimeImmutable("2024-03-31");
> > $newDt =3D $dt->setDate( month: 2 );
> >=20
> > It is now representing 2024-03-02.
> >=20
> > This might be the right answer, but it might also be that the=20
> > developer just cared about the month part (and not the=20
> > day-of-month), in which case this is a WTF moment.
> >=20
> > Picking mofication APIs is not as trivial as it seems, and I would=20
> > like to do it *right*.
> >=20
> > Feel free to add comments and wishes to the google doc document. In=20
> > the near future, I will be writing up an RFC from this.
>=20
> Thanks for your reply!
>=20
> Indeed, as per your code snippet, this is a WTF moment I had not accounte=
d for
> and confirm the same result with my patch applied. Generally, my expectat=
ion
> 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 implic=
itly
> coerce it into range, i.e. (new DateTime("2024-03-31"))->setDate(month: 2=
); =3D=3D
> 2024-02-29.

We can't do that, as it will be inconsistent with:

=09<?php
=09$d =3D new DateTimeImmutable("2024-01-31");
=09$d->modify("+1 month")
=09// (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=20
doesn't concern itself with the day-of-month at all. Setting just the=20
month should perhaps just reset the day-of-month to 1 instead. ANd=20
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=20
all of it yet.

> In particular, I cannot glean which four classes you are referring to=20
> in that document. Yet what I do find interesting is the notion of=20
> adding setters to DateTimeImmutable. For my particular=20
> use-case=E2=80=94producing a collection of dates incrementing by year in =
a=20
> Twig template=E2=80=94a trivial year setter would do just fine, with the=
=20
> significant caveat that it must implement fluent interface, because I=20
> need to call it in an expression context (returning a value), not a=20
> statement context (executing a void function separately). Not that=20
> Twig cannot execute statements, but it just becomes more verbose,=20
> cumbersome and less template-like.
>=20
> If you were happy for me to add getters and fluent setters for year,=20
> I'd be happy to work on that PR, but for month we're back to the same=20
> problem outlined in the opening paragraph (and I suppose the same=20
> problem occasionally applies to year, if the day happens to be set to=20
> the leap day). Otherwise, I'll be happy to read over your RFC when=20
> it's ready.

Feel free to add your suggestion (anywhere) in the document, preferrably=20
at the bottom :-)

I can envision that we'll have some actual setters and getters, beyond=20
just add, sub, and modify (which is really powerful).

But what is important to understand is rather *why* a specific method is=20
useful, and perhaps even more important is what you're actual goal is.

cheers,
Derick

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt

mastodon: @derickr@phpc.social @xdebug@phpc.social
--8323329-1258066982-1712155433=:14553--