Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114663
User-Agent: Cyrus-JMAP/3.5.0-alpha0-468-gdb53729b73-fm-20210517.001-gdb53729b
Mime-Version: 1.0
Message-ID: <0729fdcc-ece7-4261-ba28-9f72161495e6@www.fastmail.com>
In-Reply-To: <B57385A6-7D52-4461-B205-AE10057A0690@dafert.at>
References: <1815820036.3212683.1621007783673.JavaMail.zimbra@dafert.at>
 <CAF+90c923S_sPfCCXoih1yg8OaePxALCj6urR3TszYOuqKhTgw@mail.gmail.com>
 <B57385A6-7D52-4461-B205-AE10057A0690@dafert.at>
Date: Fri, 28 May 2021 18:48:44 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, May 28, 2021, at 5:52 PM, Mel Dafert wrote:
> >It's ... checks calendar ... the year 2021. Do we *really* need to add a
> >procedural mirror APIs, especially with such auspicious function names as
> >datepatterngenerator_get_best_pattern?
> >
> >I believe the procedural APIs are considered legacy APIs, and we are
> >intentionally not adding them for new functionality. For example, the most
> >recent intl addition (IntlChar) does not come with procedural APIs.
> 
> I wasn't aware that there was a precedent with IntlChar - the 
> documentation seems
> to frame this duplication as a feature rather than a historical 
> artifact.
> (The wording "OO style vs procedural style" does not imply any 
> endorsement
> of one style over the other to me.)
> However, i am open to only including the OO API if there is consensus - 
> although
> I feel like this should maybe belong in a separate RFC that clarifies 
> that future
> additions should prefer the OO style, and
> that the OO style is the "preferred" one.

Agreed with Nikita.  There's no compelling reason to add double-API style anymore.  It may take a second RFC to modify this one to remove those, technically, but I'd vote for it.

--Larry Garfield