I am excited to announce the start of the voting of
my latest RFC on the international extension!
It's debatable if the latest changes in response to my email constitute a major or a minor change regarding the cooldown. However there was also no email that changes *were* made to the RFC text (only that some were *planned*), which is why I didn't recheck the RFC before the vote - and the intent to vote expired.
Content-wise I also don't agree with the decision to keep using untyped constants instead of enums, but didn't have the time to actually think this through or read the RFC in-depth.
It’s debatable if the latest changes in response to my email constitute
a major or a minor change regarding the cooldown. However there was also
no email that changes were made to the RFC text (only that some were planned), which is why I didn’t recheck the RFC before the vote - and
the intent to vote expired.
I think you’ve read the RFC further after my latest response regarding
your suggestions. And I think you have no further issues with it because
you don’t send more email to the thread. Maybe I don’t have the English
skill to make it clear about what is planned and made.
Given this misunderstanding yes I will threat this as a major change and
revert the voting process.
Content-wise I also don’t agree with the decision to keep using untyped
constants instead of enums, but didn’t have the time to actually think
this through or read the RFC in-depth.
I have discussed this with David in the discussion thread. We all agree on this.
However, using untyped constants is a convention to the extension. Every other
classes in the extension don’t use enums. I’d suggest to add this in the future
scope so a extension-wide RFC can revisit this topic later. I don’t want to make
this new class special to others at the sake of consistency.
Further, using namespaces is also preferred here.
For these reasons I voted against the RFC.
Please let me know if you have further suggestions. After resolving it, I will
announce the cooldown period again. There is no need to rush anyways
I think you've read the RFC further after my latest response regarding
your suggestions. And I think you have no further issues with it because
you don't send more email to the thread. Maybe I don't have the English
skill to make it clear about what is planned and made.
No, I hadn't taken another look at the RFC yet. I also made it clear that I had not given it much thought (due to time constraints). But my schedule should not be a blocker for RFCs to proceed.
I have discussed this with David in the discussion thread. We all agree on this.
From what I see not much discussion has happened on that topic. It's basically just David suggesting it (and me previously suggesting it in private) and you declining the suggestion. I think we can find a reasonable middle-ground that makes use of enums, while not precluding a future redesign of the ext/intl API. I'll send those to the discussion thread to keep it in a single place.
در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۱۳:۰۴ Tim Düsterhus <tim@bastelstu.be> نوشت:
Hi
On 2026-09-15 14:02, Weilin Du wrote:
I think you’ve read the RFC further after my latest response regarding
your suggestions. And I think you have no further issues with it
because
you don’t send more email to the thread. Maybe I don’t have the English
skill to make it clear about what is planned and made.
No, I hadn’t taken another look at the RFC yet. I also made it clear
that I had not given it much thought (due to time constraints). But my
schedule should not be a blocker for RFCs to proceed.
>
Content-wise I also don’t agree with the decision to keep using
untyped
>
constants instead of enums, but didn’t have the time to actually think
>
this through or read the RFC in-depth.
I have discussed this with David in the discussion thread. We all agree
on this.
From what I see not much discussion has happened on that topic. It’s
basically just David suggesting it (and me previously suggesting it in
private) and you declining the suggestion. I think we can find a
reasonable middle-ground that makes use of enums, while not precluding a
future redesign of the ext/intl API. I’ll send those to the discussion
thread to keep it in a single place.
Best regards
Tim Düsterhus
Hi Tim,
Thanks for bringing this up. I completely welcome finding a reasonable middle-ground.
My long-term plan is indeed to actively contribute to ext/intl (especially aiming for PHP 8.7, where we can systematically modernize the extension with proper namespaces, enums, and cleaner error handling).
I’d be glad to see your proposed middle-ground in the main discussion thread, and we can definitely work together to align it so it fits both the current RFC requirements and the future ext/intl roadmap.