Intl: Add a new IntlListFormatter class

[BogdanUngureanu]

This PR adds support for ICU's ListFormatter implementation by implementing a new IntlListFormatter class in PHP.

The class supports ANDs, ORs and UNIT format types. However, they are only available if ICU version is 67 or above. On older versions of ICU, we only allow TYPE_AND and WIDTH_WIDE - we need this because, from what I've understood, the minimum version ICU supported is 57, which was bumped from 50 last year.

The class API is pretty simple:

$formatter = new IntlListFormatter('EN_US', IntlListFormatter::TYPE_AND, IntlListFormatter::WIDTH_WIDE);
echo $formatter->format([1,2,3]);

will display

1, 2, and 3

I have some questions here:

• Do I need to create an RFC for this new addition?
• I haven't used a namespace and used Intl prefix for consistency sake. Should it be behind a Intl namespace? I haven't seen a class that uses it so I thought I should go with the prefix.

[TimWolla]

Do I need to create an RFC for this new addition?

I wouldn't need an RFC if this is a straight forward addition to the existing Intl API which just maps to ICU in a straight forward fashion. I would like to see some smaller improvements, though:

• Making the class final and /** @not-serializable */. This allows you to avoid the “not properly constructed” checks.
• /** @strict-properties */ to further lock down the class against misuse.

I haven't used a namespace and used Intl prefix for consistency sake. Should it be behind a Intl namespace? I haven't seen a class that uses it so I thought I should go with the prefix.

The prefix makes sense to me. Using the Intl namespace should properly happen when designing an Intl API that isn't just a straight forward mapping to ICU, but also provides a nice API (e.g. enums, proper class and exception hierarchy, …).

[BogdanUngureanu]

Hi @TimWolla! Thanks for the suggestions - great ideas! I've pushed a commit that makes the class final and enabled those flags.

[TimWolla]

Some more Stub nits. Please do not add PHPDoc comments, unless they allow you to express something that the types themselves cannot.

[BogdanUngureanu]

Some more Stub nits. Please do not add PHPDoc comments, unless they allow you to express something that the types themselves cannot.

Thanks for the quick response! I'll make the changes tomorrow. :)

[devnexen]

windows CI failure is related otherwise

[devnexen]

nit: I think it makes more sense to check it before the check above it.

[devnexen]

nit: just do echo $exception->getMessage(), PHP_EOL;

[devnexen]

in theory, items[index so and so] might have make it until this failure thus you re gonna get some leaks.

[devnexen]

nit: I think RETURN_NEW_STR can be used here.

[devnexen]

do you foresee further/wider usage ? if not, it might not be useful to unnecessarily expose them and eventually put the implementations in listformatter_class, wdyt ?

[devnexen]

would it be possible to have a test triggering that case ?