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
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
--
To unsubscribe, visit: https://www.php.net/unsub.php
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
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.
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
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?
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
On Sat, May 29, 2021 at 4:25 PM Christoph M. Becker cmbecker69@gmx.de
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
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.