Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114130
User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b
Mime-Version: 1.0
Message-ID: <a7c61e24-3994-487a-a456-ab6dc0a584e6@www.fastmail.com>
In-Reply-To: <254589645.2058488.1619277132719.JavaMail.zimbra@dafert.at>
References: <254589645.2058488.1619277132719.JavaMail.zimbra@dafert.at>
Date: Sat, 24 Apr 2021 11:54:01 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Add IntlDateTimePatternGenerator
From: larry@garfieldtech.com ("Larry Garfield")

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