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
For the RFC to be precise, it probably needs to specify the rules for
initialisations explicitly.
Presumably the same as acronyms?
cheers
Dan
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
As previously announced, I would like to set an end to these
discussions
in the community:
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]
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
As previously announced, I would like to set an end to these discussions
in the community:
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
2017-06-10 20:46 GMT+02:00 Fleshgrinder php@fleshgrinder.com:
As previously announced, I would like to set an end to these discussions
in the community: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
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.
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
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
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-wordsIt'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.
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.
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.
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
As previously announced, I would like to set an end to these discussions
in the community:
Last heads-up, voting will start tomorrow!
--
Richard "Fleshgrinder" Fussenegger
As previously announced, I would like to set an end to these discussions
in the community:
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
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.
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:
--
Richard "Fleshgrinder" Fussenegger
2017-07-03 17:53 GMT+02:00 Fleshgrinder php@fleshgrinder.com:
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
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