rfc:flexible_heredoc_nowdoc_syntaxes
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:flexible_heredoc_nowdoc_syntaxes [2017/09/16 16:26] – created tpunt | rfc:flexible_heredoc_nowdoc_syntaxes [2017/11/02 11:31] – tpunt | ||
---|---|---|---|
Line 3: | Line 3: | ||
* Date: 2017-09-16 | * Date: 2017-09-16 | ||
* Author: Thomas Punt, tpunt@php.net | * Author: Thomas Punt, tpunt@php.net | ||
- | * Status: | + | * Status: |
* First Published at: https:// | * First Published at: https:// | ||
Line 39: | Line 39: | ||
// no indentation | // no indentation | ||
echo <<< | echo <<< | ||
- | a | + | |
- | b | + | |
- | c | + | c |
END; | END; | ||
/* | /* | ||
- | a | + | |
- | b | + | |
- | c | + | c |
*/ | */ | ||
- | // 1 space of indentation | + | // 4 spaces |
echo <<< | echo <<< | ||
- | a | + | |
- | b | + | |
- | c | + | c |
- | END; | + | END; |
/* | /* | ||
a | a | ||
b | b | ||
- | c | ||
- | */ | ||
- | |||
- | // 2 spaces of indentation | ||
- | echo <<< | ||
- | a | ||
- | b | ||
- | c | ||
- | END; | ||
- | /* | ||
- | a | ||
- | b | ||
- | c | ||
- | */ | ||
- | |||
- | // 3 (or more) spaces of indentation | ||
- | echo <<< | ||
- | a | ||
- | b | ||
- | c | ||
- | END; | ||
- | /* | ||
- | a | ||
- | b | ||
c | c | ||
*/ | */ | ||
</ | </ | ||
- | Tabs are supported as well. If tabs and spaces are intermixed (for whatever reason...), then each space and each tab is considered as 1 indentation. So if the closing marker is indented | + | If the closing marker is indented |
<code php> | <code php> | ||
- | // 1 tab indentation | + | |
echo <<< | echo <<< | ||
- | a | ||
- | b | ||
- | c | ||
- | END; | ||
- | /* | ||
a | a | ||
b | b | ||
c | c | ||
- | */ | + | |
+ | |||
+ | // Parse error: Invalid body indentation level (expecting an indentation at least 5) in %s on line %d | ||
</ | </ | ||
- | Moral of the story: don't mix tabs and spaces... | + | Tabs are supported as well, however, tabs and spaces **must not** be intermixed regarding the indentation |
+ | <code php> | ||
+ | // different indentation for body (spaces) ending marker (tabs) | ||
+ | { | ||
+ | echo <<< | ||
+ | a | ||
+ | END; | ||
+ | } | ||
+ | |||
+ | // mixing spaces | ||
+ | { | ||
+ | echo <<< | ||
+ | a | ||
+ | | ||
+ | } | ||
+ | |||
+ | // mixing | ||
+ | { | ||
+ | echo <<< | ||
+ | a | ||
+ | END; | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | These whitespace constraints have been included because mixing tabs and spaces for indentation is harmful to legibility. | ||
+ | |||
+ | Ultimately, the purpose of stripping leading whitespace is to allow for the body of the heredoc and nowdoc to be indented to the same level as the surrounding code, without causing unnecessary (and perhaps undesirable) whitespace to prepend each line of the body text. Without this, developers may choose to de-indent the body text to prevent leading whitespace, which leads us back to the current situation of having indentation levels of code ruined by these syntaxes. | ||
==== Closing Marker New Line ==== | ==== Closing Marker New Line ==== | ||
- | Removing | + | Currently, in order to terminate a heredoc or nowdoc, a new line **must** be used after the closing marker. Removing this requirement will change code from: |
<code php> | <code php> | ||
stringManipulator(<<< | stringManipulator(<<< | ||
Line 137: | Line 136: | ||
</ | </ | ||
- | This change was actually brought up in a previous RFC ([[rfc: | + | This change was actually brought up in a previous RFC ([[rfc: |
<code php> | <code php> | ||
$values = [<<< | $values = [<<< | ||
Line 151: | Line 150: | ||
The implementation I am proposing avoids this problem by checking to see if a continuation of the found marker exists, and if so, then if it forms a valid identifier. This means that the terminating marker string will only be considered as such if it is matched exactly as a standalone, valid symbol (that is also found at the start of the line). This enables for the above snippet to now work. | The implementation I am proposing avoids this problem by checking to see if a continuation of the found marker exists, and if so, then if it forms a valid identifier. This means that the terminating marker string will only be considered as such if it is matched exactly as a standalone, valid symbol (that is also found at the start of the line). This enables for the above snippet to now work. | ||
- | Something | + | Examples |
<code php> | <code php> | ||
$values = [<<< | $values = [<<< | ||
Line 160: | Line 159: | ||
/* | /* | ||
Parse error: syntax error, unexpected ' | Parse error: syntax error, unexpected ' | ||
+ | */ | ||
+ | |||
+ | echo <<< | ||
+ | END{$var} | ||
+ | END; | ||
+ | /* | ||
+ | Parse error: syntax error, unexpected ' | ||
*/ | */ | ||
</ | </ | ||
- | (Notice the space after the first '' | + | There is not a great deal that can be done about this. So the simple rule is: **do not choose a marker that appears in the body of the text** (though it would specifically have to occur at the start of a line in the text to cause problems). |
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
Line 170: | Line 176: | ||
* the colliding marker begins at the start of a line in the text | * the colliding marker begins at the start of a line in the text | ||
- | * the colliding marker can be seen as standalone | + | * the colliding marker can be seen as standalone, valid symbol name |
- | The changes proposed | + | The changes proposed |
- | + | ||
- | Therefore, I believe the tradeoff of making the heredoc and nowdoc syntaxes more flexible in return for requiring developers to actually choose good marker names is a tradeoff worth making. | + | |
So to quickly reiterate, the changes proposed by this RFC will enable for code such as the following: | So to quickly reiterate, the changes proposed by this RFC will enable for code such as the following: | ||
Line 181: | Line 185: | ||
{ | { | ||
stringManipulator(<<< | stringManipulator(<<< | ||
- | a | + | a |
- | b | + | b |
- | | + | c |
END | END | ||
); | ); | ||
Line 210: | Line 214: | ||
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
- | There will be two votes, both requiring a 2/3 majority. The first will be regarding whether the closing marker | + | There will be two votes, both requiring a 2/3 majority. The first will be regarding whether the closing marker |
+ | |||
+ | Voting starts on 2017.11.01 and ends on 2017-11-15. | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | '''' | ||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
===== Patches and Tests ===== | ===== Patches and Tests ===== |
rfc/flexible_heredoc_nowdoc_syntaxes.txt · Last modified: 2018/04/13 19:59 by nikic