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

From: Date: Mon, 20 Jun 2022 15:25:25 +0000
Subject: Re: [RFC] [Under Discussion] Random Extension Improvement
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-118016@lists.php.net to get a copy of this message
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. [1] <https://www.php.net/curl> [2] <https://curl.se/docs/faq.html#What_is_cURL> [3] <https://www.php.net/manual/en/class.curlfile.php> [4] <https://www.php.net/manual/en/class.curlstringfile.php> -- Christoph M. Becker

« previous php.internals (#118016) next »