Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114665
To: Mel Dafert <mel@dafert.at>, php internals <internals@lists.php.net>
References: <1815820036.3212683.1621007783673.JavaMail.zimbra@dafert.at>
 <CAF+90c923S_sPfCCXoih1yg8OaePxALCj6urR3TszYOuqKhTgw@mail.gmail.com>
 <B57385A6-7D52-4461-B205-AE10057A0690@dafert.at>
 <0729fdcc-ece7-4261-ba28-9f72161495e6@www.fastmail.com>
 <DBA4E362-44CB-4581-935A-04619ABC5B2B@dafert.at>
Message-ID: <3e8087a1-f8b3-3a7f-c048-6c61218d0710@gmx.de>
Date: Sat, 29 May 2021 16:24:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <DBA4E362-44CB-4581-935A-04619ABC5B2B@dafert.at>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 29.05.2021 at 10:02, Mel Dafert wrote:

>> Agreed with Nikita.  There's no compelling reason to add double-API sty=
le anymore.  It may take a second RFC to modify this one to remove those, =
technically, but I'd vote for it.
>
> Should this new RFC then only apply to IntlDatePatternGenerator, or shou=
ld it also
> clarify that future additions to the intl extension (or to extensions in=
 general?)
> should not add both styles and prefer OO style if possible?

IMO, an RFC which generally "forbids" the introduction of new dual APIs
would make sense.  I don't think that we *need* an RFC to remove the
procedural API of IntlDatePatternGenerator.

Christoph