Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE] Add IntlDatePatternGenerator »

[VOTE] Add IntlDatePatternGenerator

php.internals

Mel Dafert

5 years ago
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

Mel Dafert

5 years ago
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

Nikita Popov

5 years ago
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

Mel Dafert

5 years ago
>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.

Larry Garfield

5 years ago
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

Mel Dafert

5 years ago
>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?

Christoph Becker

5 years ago
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

Nikita Popov

5 years ago
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

Mel Dafert

5 years ago
>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.