[VOTE] Add IntlDatePatternGenerator

  114473
May 14, 2021 15:56 mel@dafert.at (Mel Dafert)
Hi Internals,
I have opened the vote on https://wiki.php.net/rfc/intldatetimepatterngenerator.
I will close it on 2021-05-28.

For previous discussion see https://externals.io/message/113831 and https://externals.io/message/114124.

Regards,
Mel
  114656
May 28, 2021 14:13 mel@dafert.at (Mel Dafert)
Hi Internals,

I am pleased to announce that this RFC has been accepted unanimously.
I have closed the vote.

Regards,
Mel

----- Original Message -----
From: "Mel Dafert" <mel@dafert.at>
To: "internals" <internals@lists.php.net>
Sent: Friday, May 14, 2021 5:56:23 PM
Subject: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator

Hi Internals,
I have opened the vote on https://wiki.php.net/rfc/intldatetimepatterngenerator.
I will close it on 2021-05-28.

For previous discussion see https://externals.io/message/113831 and https://externals.io/message/114124.

Regards,
Mel

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
  114658
May 28, 2021 14:51 nikita.ppv@gmail.com (Nikita Popov)
On Fri, May 14, 2021 at 5:56 PM Mel Dafert <mel@dafert.at> wrote:

> Hi Internals, > I have opened the vote on > https://wiki.php.net/rfc/intldatetimepatterngenerator. > I will close it on 2021-05-28. > > For previous discussion see https://externals.io/message/113831 and > https://externals.io/message/114124. > > Regards, > Mel >
A bit late, but I have a small note on this RFC: It's ... checks calendar ... the year 2021. Do we *really* need to add a procedural mirror APIs, especially with such auspicious function names as datepatterngenerator_get_best_pattern? I believe the procedural APIs are considered legacy APIs, and we are intentionally not adding them for new functionality. For example, the most recent intl addition (IntlChar) does not come with procedural APIs. Regards, Nikita
  114662
May 28, 2021 22:52 mel@dafert.at (Mel Dafert)
>It's ... checks calendar ... the year 2021. Do we *really* need to add a >procedural mirror APIs, especially with such auspicious function names as >datepatterngenerator_get_best_pattern? > >I believe the procedural APIs are considered legacy APIs, and we are >intentionally not adding them for new functionality. For example, the most >recent intl addition (IntlChar) does not come with procedural APIs.
I wasn't aware that there was a precedent with IntlChar - the documentation seems to frame this duplication as a feature rather than a historical artifact. (The wording "OO style vs procedural style" does not imply any endorsement of one style over the other to me.) However, i am open to only including the OO API if there is consensus - although I feel like this should maybe belong in a separate RFC that clarifies that future additions should prefer the OO style, and that the OO style is the "preferred" one.
  114663
May 28, 2021 23:48 larry@garfieldtech.com ("Larry Garfield")
On Fri, May 28, 2021, at 5:52 PM, Mel Dafert wrote:
> >It's ... checks calendar ... the year 2021. Do we *really* need to add a > >procedural mirror APIs, especially with such auspicious function names as > >datepatterngenerator_get_best_pattern? > > > >I believe the procedural APIs are considered legacy APIs, and we are > >intentionally not adding them for new functionality. For example, the most > >recent intl addition (IntlChar) does not come with procedural APIs. > > I wasn't aware that there was a precedent with IntlChar - the > documentation seems > to frame this duplication as a feature rather than a historical > artifact. > (The wording "OO style vs procedural style" does not imply any > endorsement > of one style over the other to me.) > However, i am open to only including the OO API if there is consensus - > although > I feel like this should maybe belong in a separate RFC that clarifies > that future > additions should prefer the OO style, and > that the OO style is the "preferred" one.
Agreed with Nikita. There's no compelling reason to add double-API style anymore. It may take a second RFC to modify this one to remove those, technically, but I'd vote for it. --Larry Garfield
  114664
May 29, 2021 08:02 mel@dafert.at (Mel Dafert)
>Agreed with Nikita. There's no compelling reason to add double-API style anymore. It may take a second RFC to modify this one to remove those, technically, but I'd vote for it.
Should this new RFC then only apply to IntlDatePatternGenerator, or should it also clarify that future additions to the intl extension (or to extensions in general?) should not add both styles and prefer OO style if possible?
  114665
May 29, 2021 14:24 cmbecker69@gmx.de ("Christoph M. Becker")
On 29.05.2021 at 10:02, Mel Dafert wrote:

>> Agreed with Nikita. There's no compelling reason to add double-API style anymore. It may take a second RFC to modify this one to remove those, technically, but I'd vote for it. > > Should this new RFC then only apply to IntlDatePatternGenerator, or should it also > clarify that future additions to the intl extension (or to extensions in general?) > should not add both styles and prefer OO style if possible?
IMO, an RFC which generally "forbids" the introduction of new dual APIs would make sense. I don't think that we *need* an RFC to remove the procedural API of IntlDatePatternGenerator. Christoph
  114673
May 31, 2021 09:40 nikita.ppv@gmail.com (Nikita Popov)
On Sat, May 29, 2021 at 4:25 PM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 29.05.2021 at 10:02, Mel Dafert wrote: > > >> Agreed with Nikita. There's no compelling reason to add double-API > style anymore. It may take a second RFC to modify this one to remove > those, technically, but I'd vote for it. > > > > Should this new RFC then only apply to IntlDatePatternGenerator, or > should it also > > clarify that future additions to the intl extension (or to extensions in > general?) > > should not add both styles and prefer OO style if possible? > > IMO, an RFC which generally "forbids" the introduction of new dual APIs > would make sense. I don't think that we *need* an RFC to remove the > procedural API of IntlDatePatternGenerator. >
Right, for the purposes of this RFC, it's okay to just drop them if there are no objections. A general policy RFC may still be useful for future reference. Nikita
  114677
May 31, 2021 13:42 mel@dafert.at (Mel Dafert)
>Right, for the purposes of this RFC, it's okay to just drop them if there >are no objections. A general policy RFC may still be useful for future >reference.
In that case, I will just go ahead and remove the procedural style from my implementation (unless someone speaks up and objects). I will move the general discussion to a new thread.