ext/intl: GH-17006 part 1, NumberFormat and NumberFormatter co-existing.

[devnexen]

Those APIs are not particularly 1:1, here using NumberFormatter for NumberFormatter::format/numft_format at the moment, trying to assess what's possible for next.

[devnexen]

cc @cmb69 when you get the chance .. no need to be too "pedantic" about details for now just to know if I m heading in the right direction(s).

[cmb69]

Hmm, not sure whether this approach is the best idea. Maybe it's better to postpone using NumberFormatter to PHP 9 (what might be next after 8.5), and than to require ICU >= 60.1, and let userland handle the BC break.

Another option might be to additionally support NumberFormatter for 8.5, but as explicit opt-in from userland (and of course only possible with ICU >= 60.1).

Perhaps this should be discussed on the internal mailing list first.

[devnexen]

Thanks for your time. I would rather aim 9.0 but ideally there should be no change in the php POV, do not know if writing to ML is enough in that case ?

[BogdanUngureanu]

@devnexen Imo, having both implementations in the same PHP class might cause some complications if we'll try to implement other ICU classes/functions that depend on the NumberFormatter.

Some ICU classes like RelativeDateTimeFormatter accepts the old NumberFormat, while newer classes like NumberRangeFormatter use the newer NumberFormatter.

I mean, sure, there might be some checks at runtime that validates if the right NF is used, but imho this sounds like a bad API design and a bit opaque.

What do you think if we do the same thing ICU did and implement a separate class? For example, we could namespace it like Intl\NumberFormatter and leave the existing one as it is.

[devnexen]

Seeing that both do not match feature wise and NumberFormat is going to be obsolete, it makes more sense to separate them. Only needs to work out future missing features (e.g. currency parsing I believe).