Re: [PHP-DEV] [RFC] IntlRelativeDateTimeFormatter

Hi Ignace, David,


Thanks for the feedback. IMHO I tend to not accept Duration object as a parameter. 


IntlRelativeDateTimeFormatter formats a caller-selected offset and unit. Time\Duration
represents stopwatch time as seconds and nanoseconds. This cause a huge amount of
issue which immediately comes into my head when thinking of this. 


The API looks like


$fmt->format(3, UNIT_DAY);    // in 3 days
$fmt->format(2, UNIT_MONTH);  // in 2 months
$fmt->format(-1, UNIT_SUNDAY);// last Sunday


If we are now accepting Durations, they look like


Time\Duration::fromMinutes(90)


We don't know how to deal with 90 minutes here. It can be 90 minutes or 1.5 hour.


Nevertheless, what about weekdays? things like UNIT_SUNDAY are not durations.
Not to mention months, quarters, and years need calendar context.


For enums and namespaces: I kept class constants and the global Intl* class name to stay
consistent with the existing ext/intl API, such as IntlDateFormatter, IntlListFormatter
IntlNumberRangeFormatter, and IntlDatePatternGenerator. I don't want to make
IntlRelativeDateTimeFormatter somehow special here just because this is added later.
I agree that enums and namespaces would be nicer in isolation, *indeed*. But, 
introducing them for only this one formatter would make the API inconsistent with the rest
of ext/intl.


For the second argument of ureldatefmt_open(): the initial implementation will pass NULL,
so ICU uses the default number formatter for the selected locale. *This is intended.*
Exposing a custom NumberFormatter is possible future scope, but it needs extra care
because ICU adopts ownership of the supplied UNumberFormat, so PHP would need to
clone the underlying formatter before passing it to ICU.


What do you think?


Cheers,
Weilin