Re: [RFC] [Under Discussion] Random Extension Improvement

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年6月20日(月) 23:37 Lynn <kjarli@gmail.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 not > >>> 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 are > >> 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 like 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 added 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 is > 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 is > 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-functionsmethods-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