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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
