Re: [RFC] Add IntlDateTimePatternGenerator

On Sat, Apr 24, 2021, at 10:12 AM, Mel Dafert wrote: > Hi Internals, > > I would like to propose an RFC > https://wiki.php.net/rfc/intldatetimepatterngenerator to add > IntlDateTimePatternGenerator > which exposes ICU's ability to flexibly create localized date/time > formatting patterns from a skeleton. > > Previous discussion: https://externals.io/message/113831 > Implementation: https://github.com/php/php-src/pull/6771 > > Proposed signature: > ``` > class IntlDateTimePatternGenerator > { > public function __construct(?string $locale = null) {} > > public static function create(?string $locale = null): > ?IntlDateTimePatternGenerator {} > > public function getBestPattern(string $skeleton): string|false {} > } > ``` > > There is an open question about what this should be named > IntlDatePatternGenerator instead, both for brevity and to keep > consistency > with IntlDateFormatter. (Note that the underlying ICU classes > are > called DateTimePatternGenerator and > DateFormatter, respectively.) > I am open to switching to the shorter form. > > Another open question is the signature, as currently both > __construct > and create are exposed (like > IntlDateFormatter). > Other classes inside the intl extension (like IntlCalendar) > only > provide a static create method, and leave the > __construct method > private. Is there a preferred way, or are both equivalent? For both points, I'd say "consistency wins by default." So if the other classes in that package already skip "Time" and use ::create() instead of a constructor, you should do the same as well unless there's a very good reason not to. (Consistency with everything else in PHP that's not that package is a possible reason not to, I grant, hence why it's somewhat subjective.) --Larry Garfield