# [VOTE] Add IntlDatePatternGenerator - Thread: https://externals.io/message/114473 - Original archive: https://news-web.php.net/php.internals/114473 - Started by Mel Dafert on 2021-05-14T15:56:23+00:00 - Messages: 9 - RFC: Remove functions with overloaded signatures (Accepted) — https://externals.io/rfc/deprecate_functions_with_overloaded_signatures.md - RFC: Add IntlDatePatternGenerator (Implemented (PHP 8.1)) — https://externals.io/rfc/intldatetimepatterngenerator.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #114473 — Mel Dafert — 2021-05-14T15:56:23+00:00 URL: https://externals.io/message/114473#114473 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 — Mel Dafert — 2021-05-28T14:13:04+00:00 URL: https://externals.io/message/114473#114656 · In reply to: #114473 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" To: "internals" 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 -- To unsubscribe, visit: https://www.php.net/unsub.php --- ## #114658 — Nikita Popov — 2021-05-28T14:51:17+00:00 URL: https://externals.io/message/114473#114658 · In reply to: #114473 > 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 — Mel Dafert — 2021-05-28T22:52:58+00:00 URL: https://externals.io/message/114473#114662 · In reply to: #114658 >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 — Larry Garfield — 2021-05-28T23:48:44+00:00 URL: https://externals.io/message/114473#114663 · In reply to: #114662 > > […] > > 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 — Mel Dafert — 2021-05-29T08:02:32+00:00 URL: https://externals.io/message/114473#114664 · In reply to: #114663 >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 — Christoph M. Becker — 2021-05-29T14:24:50+00:00 URL: https://externals.io/message/114473#114665 · In reply to: #114664 > > […] > > 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 — Nikita Popov — 2021-05-31T09:40:31+00:00 URL: https://externals.io/message/114473#114673 · In reply to: #114665 On Sat, May 29, 2021 at 4:25 PM Christoph M. Becker wrote: > > > > […] > style anymore. It may take a second RFC to modify this one to remove > those, technically, but I'd vote for it. > > […] > should it also > > […] > general?) > > […] > > 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 — Mel Dafert — 2021-05-31T13:42:54+00:00 URL: https://externals.io/message/114473#114677 · In reply to: #114673 >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.