Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] [Discussion] Class Naming »

[RFC] [Discussion] Class Naming

php.internals

Fleshgrinder

9 years ago
As previously announced, I would like to set an end to these discussions in the community: https://wiki.php.net/rfc/class-naming
-- Richard "Fleshgrinder" Fussenegger

Dan Ackroyd

9 years ago
On 3 June 2017 at 13:03, Fleshgrinder <php@fleshgrinder.com> wrote:
> https://wiki.php.net/rfc/class-naming
For the RFC to be precise, it probably needs to specify the rules for initialisations explicitly. Presumably the same as acronyms? cheers Dan

Fleshgrinder

9 years ago
On 6/3/2017 3:20 PM, Dan Ackroyd wrote:
> On 3 June 2017 at 13:03, Fleshgrinder <php@fleshgrinder.com> wrote: >> https://wiki.php.net/rfc/class-naming > > For the RFC to be precise, it probably needs to specify the rules for > initialisations explicitly. > > Presumably the same as acronyms? > > cheers > Dan >
Thanks, I updated the RFC and PRs accordingly. Acronyms and initialisms are basically the same thing, the differentiation is only important for spoken language. Still good to cover right away, so very good catch! I also added a special case with Radar to the examples. Some acronyms are not all-upper in their standard notation, hence, they should't be in our code.
-- Richard "Fleshgrinder" Fussenegger

Rowan Collins

9 years ago
On 3 June 2017 13:03:20 BST, Fleshgrinder <php@fleshgrinder.com> wrote:
>As previously announced, I would like to set an end to these >discussions >in the community: > >https://wiki.php.net/rfc/class-naming
Hi Richard, I think 3-way votes are potentially confusing, and saying it's a "simple 50%+1 majority vote" doesn't really make sense if it's not a yes/no question. What if the vote splits 49/48/3? Does "do nothing" win because the other options didn't pass the winning post, even though some people would actually be happy with either option? I don't think there are many people who would rank the options as A > neither > B in this case. Perhaps it would be better to separate the vote in two: - Should coding standard be changed? Yes / No, 50%+1 required for change - Which style should be used if change is accepted? A / B, highest total wins regardless of proportion. Regards,
-- Rowan Collins [IMSoP]

Fleshgrinder

9 years ago
On 6/3/2017 4:07 PM, Rowan Collins wrote:
> Hi Richard, > > I think 3-way votes are potentially confusing, and saying it's a > "simple 50%+1 majority vote" doesn't really make sense if it's not a > yes/no question. > > What if the vote splits 49/48/3? Does "do nothing" win because the > other options didn't pass the winning post, even though some people > would actually be happy with either option? I don't think there are > many people who would rank the options as A > neither > B in this > case. > > Perhaps it would be better to separate the vote in two: - Should > coding standard be changed? Yes / No, 50%+1 required for change - > Which style should be used if change is accepted? A / B, highest > total wins regardless of proportion. > > Regards, >
You are completely right, this makes no sense as it stands. Changed to how you propose it, as it is the only thing that actually makes sense. ;)
-- Richard "Fleshgrinder" Fussenegger

Fleshgrinder

9 years ago
On 6/3/2017 2:03 PM, Fleshgrinder wrote:
> As previously announced, I would like to set an end to these discussions > in the community: > > https://wiki.php.net/rfc/class-naming >
I am planning to put this to vote tomorrow, unless somebody has serious concerns and raises them here. The minimum discussion time of one week has passed, and this RFC has no impact on the language itself.
-- Richard "Fleshgrinder" Fussenegger

Niklas Keller

9 years ago
2017-06-10 20:46 GMT+02:00 Fleshgrinder <php@fleshgrinder.com>:
> On 6/3/2017 2:03 PM, Fleshgrinder wrote: > > As previously announced, I would like to set an end to these discussions > > in the community: > > > > https://wiki.php.net/rfc/class-naming > > > > I am planning to put this to vote tomorrow, unless somebody has serious > concerns and raises them here. The minimum discussion time of one week > has passed, and this RFC has no impact on the language itself. >
The minimum discussion period is two weeks. Regards, Niklas

Fleshgrinder

9 years ago
On 6/10/2017 10:54 PM, Niklas Keller wrote:
> The minimum discussion period is two weeks. > > Regards, Niklas
Not according to our rules, no:
> There'd be a minimum of 2 weeks between when an RFC that touches the > language is brought up on this list and when it's voted on is > required. Other RFCs might use a smaller timeframe, but it should be > at least a week. > > --- https://wiki.php.net/rfc/voting#discussion_period
This RFC is only about a tiny extension of the coding standards, no other change to PHP is proposed. Hence, one week seems sensible. We can of course wait if there is a serious issue.
-- Richard "Fleshgrinder" Fussenegger

Dan Ackroyd

9 years ago
On 10 June 2017 at 21:57, Fleshgrinder <php@fleshgrinder.com> wrote:
> > This RFC is only
"When collaborating with others – especially when designers and programmers are part of the mix – watch out for these dirty four letter words: Need Must Can’t Easy Just Only Fast" https://signalvnoise.com/posts/439-four-letter-words It's actually setting a rule for a project, that has gone 23 years without needing that rule, which doesn't sound completely trivial.
> Hence, one week seems sensible.
It doesn't seem sensible to me. The minimum discussion period is for when there is an urgent problem that ought to be addressed but there is disagreement about the best way to resolve it. We should be taking longer periods to think about committing to coding standards, rather than just the bare minimum. People (in general) have better things to do than read internals. Some of the discussions over the past couple of weeks have been even more demotivating than usual, which is probably one of the reasons why people haven't responded yet.
> We can of course wait if there is a serious issue.
We can of course wait anyway. This RFC isn't going to affect 7.2, so the first release it will affect is 7.3 - so we could wait 12 months to vote before it became critical. cheers Dan

Fleshgrinder

9 years ago
On 6/11/2017 12:35 AM, Dan Ackroyd wrote:
> On 10 June 2017 at 21:57, Fleshgrinder <php@fleshgrinder.com> wrote: >> >> This RFC is only > > "When collaborating with others – especially when designers and > programmers are part of the mix – watch out for these dirty four > letter words: Need Must Can’t Easy Just Only Fast" > https://signalvnoise.com/posts/439-four-letter-words > > It's actually setting a rule for a project, that has gone 23 years > without needing that rule, which doesn't sound completely trivial. >
It is a clarification of an existing rule. A rule that already exists for 16 years. On 6/11/2017 12:35 AM, Dan Ackroyd wrote:
>> Hence, one week seems sensible. > > It doesn't seem sensible to me. > > The minimum discussion period is for when there is an urgent problem > that ought to be addressed but there is disagreement about the best > way to resolve it. >
The existing rules are pretty explicit about their intend and applicability. Not sure where this is coming from. On 6/11/2017 12:35 AM, Dan Ackroyd wrote:
> We should be taking longer periods to think about committing to coding > standards, rather than just the bare minimum. >
Here I agree in general, but the RFC's question is trivial and its choices are obvious. That is why I believe that it does not require much though. On 6/11/2017 12:35 AM, Dan Ackroyd wrote:
> People (in general) have better things to do than read internals. Some > of the discussions over the past couple of weeks have been even more > demotivating than usual, which is probably one of the reasons why > people haven't responded yet. > >> We can of course wait if there is a serious issue. > > We can of course wait anyway. > > This RFC isn't going to affect 7.2, so the first release it will > affect is 7.3 - so we could wait 12 months to vote before it became > critical. > > cheers > Dan >
Seems like people have serious issues, so let's wait.
-- Richard "Fleshgrinder" Fussenegger

Fleshgrinder

9 years ago
On 6/3/2017 2:03 PM, Fleshgrinder wrote:
> As previously announced, I would like to set an end to these discussions > in the community: > > https://wiki.php.net/rfc/class-naming >
Last heads-up, voting will start tomorrow!
-- Richard "Fleshgrinder" Fussenegger

Fleshgrinder

9 years ago
On 6/3/2017 2:03 PM, Fleshgrinder wrote:
> As previously announced, I would like to set an end to these discussions > in the community: > > https://wiki.php.net/rfc/class-naming >
Last call for comments. Four weeks have passed and I would like to start the voting phase on this one. Voting will start on Saturday around 4 PM UTC and last for two weeks if no concerns are raised here.
-- Richard "Fleshgrinder" Fussenegger

Andreas Treichel

9 years ago
With any exception from PascalCase you cannot e.g. generate class names from strings without a explicit mapping table: <?php function findParserByRootNode(DomDocument $document) { $tagName = $document->documentElement->tagName; $className = ucfirst($tagName) . 'Parser'; if (!class_exists($className)) { throw new RuntimeException('Parser not found for '.$tagName); } return new $className(); } $document = new DomDocument(); $document->loadXml($xml); $parser = findParserByRootNode($document); $parser->parse($document); acronyms in PascalCase looks strange, but consistent strange.

Fleshgrinder

9 years ago
On 7/3/2017 5:30 PM, Andreas Treichel wrote:
> With any exception from PascalCase you cannot e.g. generate class names > from strings without a explicit mapping table: > > <?php > > function findParserByRootNode(DomDocument $document) > { > $tagName = $document->documentElement->tagName; > $className = ucfirst($tagName) . 'Parser'; > if (!class_exists($className)) { > throw new RuntimeException('Parser not found for '.$tagName); > } > return new $className(); > } > > $document = new DomDocument(); > $document->loadXml($xml); > > $parser = findParserByRootNode($document); > $parser->parse($document); > > > > acronyms in PascalCase looks strange, but consistent strange. > >
Not true in PHP because class names are not case sensitive: https://3v4l.org/bcAAC
-- Richard "Fleshgrinder" Fussenegger

Niklas Keller

9 years ago
2017-07-03 17:53 GMT+02:00 Fleshgrinder <php@fleshgrinder.com>:
> On 7/3/2017 5:30 PM, Andreas Treichel wrote: > > With any exception from PascalCase you cannot e.g. generate class names > > from strings without a explicit mapping table: > > > > <?php > > > > function findParserByRootNode(DomDocument $document) > > { > > $tagName = $document->documentElement->tagName; > > $className = ucfirst($tagName) . 'Parser'; > > if (!class_exists($className)) { > > throw new RuntimeException('Parser not found for '.$tagName); > > } > > return new $className(); > > } > > > > $document = new DomDocument(); > > $document->loadXml($xml); > > > > $parser = findParserByRootNode($document); > > $parser->parse($document); > > > > > > > > acronyms in PascalCase looks strange, but consistent strange. > > > > > > Not true in PHP because class names are not case sensitive:
While true, most applications actually depend on the case for class names because of autoloaders. Regards, Niklas

Fleshgrinder

9 years ago
On 7/3/2017 7:18 PM, Niklas Keller wrote:
> While true, most applications actually depend on the case for class > names because of autoloaders. > > Regards, Niklas >
Nobody is auto-loading internal classes, they are auto-loaded by PHP. That is the only thing this vote is about. PS: Note that I personally would vote for "always PascalCase" because context awareness is a bad thing when it comes to such things as naming. However, I have no vote and the current landscape of PHP internals goes more in the "except acronyms" direction. It is up to the voters, but the casing is not an issue for this vote, that's all I'm sayin'.
-- Richard "Fleshgrinder" Fussenegger