Edit report at https://bugs.php.net/bug.php?id=75138&edit=1
ID: 75138
Comment by: peehaa@php.net
Reported by: jcmarchi at gmail dot com
Summary: Nested "IF" triggers Exception when it is before
"else:" or "elseif:".
Status: Not a bug
Type: Bug
Package: *Programming Data Structures
Operating System: All
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
I am sorry for you, but as several people by now have stated: this is not a bug.
No matter how many personal attacks on volunteers or how loud you are shouting it will not the
status of this bug report. :-)
At this point I see no reason to keep going at it.
So I would suggest you to do just that.
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system
is not the
appropriate forum for asking support questions. The support channels will be able to provide an
explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
------------------------------------------------------------------------
[2017-08-31 16:15:23] jcmarchi at gmail dot com
Ok. Very well... I can accept it as not being a "BUG", but a "NEW SYNTAX
requirement" (rules are rules). Next, it must be added to the language manual definition in
regards to semicolon usage and purpose.
I then propose the following addition to the PHP official documentation:
====================
When using "alternative syntax for control structures" observe the fact that when an
"IF" statement is required to be nested into another IF-ELSEIF-ELSE block and it casually
ends up being the last statement of the nested block, it is a LANGUAGE REQUIREMENT to terminate it
with double semicolon (;;) to prevent the "dangling else" effect.
====================
Or, better, we can add it to the same (miss)interpretation concept, keeping documentation standards:
====================
Note:
Mixing syntaxes in the same control block is not supported.
Note:
A nested "if" statement immediately before an "else:" or "elseif: "
statement in control block is not supported.
====================
Or, even better! Let's simply ignore it all and leave it as it is. What harm can an extra
";" do anyway, right?
Well done everyone. Good job!
------------------------------------------------------------------------
[2017-08-31 14:34:00] requinix@php.net
If you want a fifth opinion, I agree with peehaa, nikic, rhsoft, and yohgaki: this isn't a bug.
The second semicolon you're making a fit about changes the meaning of the structure. It
introduces another statement (even if empty) and breaks the if/else pair apart, thus avoiding the
dangling else problem. https://3v4l.org/0vsMV
It's not a workaround. It's syntax.
------------------------------------------------------------------------
[2017-08-31 14:20:35] jcmarchi at gmail dot com
@peehaa, you should re-open this BUG report because IT IS a bug! Or, at least, have the decency to
gather a second opinion about it. You came to a conclusion too quickly and based on a sole visual
analysis of the code samples (I bet you didn't even try some scenarios, did you?), and also by
misinterpreting the PHP manual guidance... :S
If a double semicolon ";;" or a semicolon after the closing curly bracket "};"
requirement to fix a code parsing problem is not considered a bug, then I don't know what will
ever be.
By keeping this BUG REPORT open, other PHP developers (more willing to really make PHP better), will
have a chance to look into it and come up with a real solution.
Thank you.
------------------------------------------------------------------------
[2017-08-30 23:56:33] jcmarchi at gmail dot com
@spam2, YES, I read it. More than that, I analyzed what is said there, I read more about
"scannerless parsing" (not the case because it doesn't apply to PHP, which is
bytecode by Zend Engine) and other processes discussed there, and I understood the whole discussion
around the "dangling else" condition for the languages that are affected by it (PHP is not
one of them).
As much as it would be easy to simply accept that, read my answer to @yohgaki. He brought material
to research and added good points to the discussion, but sadly it didn't explain what I replied
to him, neither excused PHP from behaving the way it behaves for in the proposed conditions.
You should really try some code samples. Create your own! Target the ";;" and
"};" specific examples as reference. Remove these elements, redesign the logic without
"unnesting" the problematic code. Prove me wrong about the bug or explain how
";;" and "};" fixes the issue even when it is not part of PHP concept and
remember: "blank lines" should not affect the logic in place.
Then this discussion may get to a valuable conclusion or an acceptance of the BUG existence. :)
------------------------------------------------------------------------
[2017-08-30 23:36:20] jcmarchi at gmail dot com
@yohgaki, thank you for providing valuable insight to the (so far) useless discussion!
The parsing issue in the PHP case can be easily observed in the "double semicolon"
example. The question is: why, when adding an extra semicolon before the "else:" or
"elseif:" magically resolves the "nested IF" problem? After all, in PHP, blank
lines should not affect the logic, right? Well, in this case, IT DOES!
It is not exactly ambiguity problem as no more than one correct parse tree actually exist (only in
the eye of the blind ones). If an "IF" statement nested block begins with ":"
and ends when an "else:" or "elseif:" is found, the "nested IFs"
should all work or fail equivalently, but just the last "IF" fails (and it doesn't
have a ":" to create ambiguity).
It is crazy to see people who should be going to the PHP Source Code and look for answers (or
solutions), or even bring something factual to the table, discussing the quality of "code
samples". The only things that matter in those samples are the ";;" and
"};", which fixes the "nested IF" issue, and AFAIK such approach is not even
part of the PHP coding principle.
It is depressing, if not tragic!
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=75138
--
Edit this bug report at https://bugs.php.net/bug.php?id=75138&edit=1