Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118034
MIME-Version: 1.0
References: <CAMs36HcGzvwwTTU+nUO+U_M6o4qpOAHES7RbHEJWm6iot+-9=Q@mail.gmail.com>
 <CAC5V6gj04Qi7C-4UCXeF003u_jKUT9cuqTD8xzPQ06CDMJhURw@mail.gmail.com>
 <CANS-=pdDZJ+8yndFmebPZu5S3VXjFr-OW93ndpbkk_+JD9=zxw@mail.gmail.com>
 <CABTDVhBY3L87PNyT9OZ72PN90qQ6C1Ngz8YRJYuTsqgpkrnNug@mail.gmail.com>
 <376a90af-8709-012c-76ee-fa351d1b017c@gmx.de> <CAC5V6gghhFJDxKSgXdWYEc5P3siTVxTkO=JdH10qMisPBDiwZg@mail.gmail.com>
In-Reply-To: <CAC5V6gghhFJDxKSgXdWYEc5P3siTVxTkO=JdH10qMisPBDiwZg@mail.gmail.com>
Date: Tue, 21 Jun 2022 20:38:35 +0900
Message-ID: <CAMs36Hehe_Ms8=EmV6WvCZF4zOgu9yvd8rONH_fR6bRM8Y4-aA@mail.gmail.com>
To: Guilliam Xavier <guilliam.xavier@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000d47f2c05e1f3a95b"
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension Improvement
From: g-kudo@colopl.co.jp (Go Kudo)

--000000000000d47f2c05e1f3a95b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2022=E5=B9=B46=E6=9C=8821=E6=97=A5(=E7=81=AB) 18:23 Guilliam Xavier <guilli=
am.xavier@gmail.com>:

> On Mon, Jun 20, 2022 at 5:25 PM Christoph M. Becker <cmbecker69@gmx.de>
> wrote:
> >
> > On 20.06.2022 at 16:44, Go Kudo wrote:
> >
> > > 2022=E5=B9=B46=E6=9C=8820=E6=97=A5(=E6=9C=88) 23:37 Lynn <kjarli@gmai=
l.com>:
> > >
> > >> On Mon, Jun 20, 2022 at 3:15 PM Guilliam Xavier <
> guilliam.xavier@gmail.com
> > >> wrote:
> > >>
> > >>>> https://wiki.php.net/rfc/random_extension_improvement
> > >>>
> > >>> Thanks, but I am not sure about your argument in "Classnames are no=
t
> > >>> canonicalized": does "PHP applies strict PascalCase to class names"
> > >>> (which remains to be proved) really imply to rename *acronyms* (e.g=
.
> > >>> "CombinedLCG" to "CombinedLcg")? especially given existing classes
> > >>> like "SimpleXMLElement" (not "SimpleXmlElement"), and that the
> > >>> accepted "Class Naming" RFC (https://wiki.php.net/rfc/class-naming)
> > >>> voted for "PascalCase except Acronyms" (not "Always PascalCase") --
> > >>> excerpts:
> > >>
> > >> Not specifically directed at this discussion, but perhaps this needs=
 a
> > >> revision. HTTPStatus is much harder to read for me than HttpStatus
> and it's
> > >> unclear where the boundary of an acronym starts or stops. If anyone
> ever
> > >> decides to make an RFC for this, you have my vote. These Acronyms ar=
e
> > >> treated as words and thus should follow the same naming convention.
> If they
> > >> shouldn't be treated as words, write their full name:
> > >> HypertextTransferProtocolStatus.
> > >
> > > I support "PascalCase except Acronyms" for readability, but would lik=
e
> to
> > > see this
> > > clarified as I get very lost when implementing new features.
> > > I think it is necessary because I expect various OO APIs will be adde=
d
> in
> > > the future,
> > > like cURL.
> >
> > In my opinion, <https://wiki.php.net/rfc/class-naming> was a bit
> > unfortunate.  It may have been better to decide on a case by case basis=
.
> >
> > For instance, we have introduced several Curl* classes in PHP 8.0[1],
> > and these adhere to the appropriate example in the RFC, although CURL i=
s
> > clearly an acronym[2], and the canonical spelling is even cURL.  Maybe
> > even worse, the previously introduced CURLFile[3] uses different
> > capitalization, and CURLStringFile[4] which was introduced in PHP 8.1 i=
s
> > aligned to that spelling.
> >
> > So, obviously, the RFC didn't have a good impact on some of the namings
> > so far.
>
> That seems unfortunate indeed :/ and there are others, e.g.
> "XMLReader" but "XmlParser"... Moreover, I see that
>
> https://github.com/php/php-src/blob/master/CODING_STANDARDS.md#user-funct=
ionsmethods-naming-conventions
> item 7 only says "should", not "must".
>
> I too find "HttpStatus" [or "HTTP_status", for that matter] more
> readable than "HTTPStatus" (where I first see "HTTPS" before noticing
> that the S actually starts a second word), and "PcgOneseq128XslRr64"
> than "PCGOneseq128XSLRR64" (especially if not already familiar with
> "PCG" and "XSL-RR")...
>
> So, it may indeed be OK (and preferred?) to "canonicalize" the
> proposed class names (just, "PHP applies strict PascalCase to class
> names" wasn't a good argument for it).
>
> PS @Go Kudo: please don't be offended, but in general, maybe you
> should wait "a bit more" [or even ask] for other opinions, rather than
> changing the RFC "too fast" after only one (especially when I said "I
> am not sure" and asked a question)
>
> Regards,
>
> --
> Guilliam Xavier
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Hi

It's a difficult problem...

At least in this thread, "Always PascalCase" seems to be more favored.
(I know this is probably not the best way to put it, but I can't think of
any other analogy...)

I am wondering how to write to the RFC, but if there are no problems, I
will make the following changes.

- Change to `Randomizer::pickArrayKey(array $array, int $num =3D 1):
int|string|array` -> `Randomizer::pickArrayKeys(array $array, int $num):
array`
- Apply "Always PascalCase" based on ML's opinion

> PS

Thanks for the advice. I am not very familiar with the OSS community, so it
helps a lot.

Regards
Go Kudo

--000000000000d47f2c05e1f3a95b--