rfc:flexible_heredoc_nowdoc_syntaxes
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:flexible_heredoc_nowdoc_syntaxes [2017/09/27 10:46] – 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 93: | Line 93: | ||
{ | { | ||
echo <<< | echo <<< | ||
- | a | + | |
END; | END; | ||
} | } | ||
Line 99: | Line 99: | ||
These whitespace constraints have been included because mixing tabs and spaces for indentation is harmful to legibility. | 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 ==== | ||
- | Currently, in order to terminate a heredoc or nowdoc, a new line **must** be used after the closing marker | + | Currently, in order to terminate a heredoc or nowdoc, a new line **must** be used after the closing marker. Removing |
- | Removing | + | |
<code php> | <code php> | ||
stringManipulator(<<< | stringManipulator(<<< | ||
Line 135: | 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 177: | Line 178: | ||
* the colliding marker can be seen as standalone, valid symbol name | * 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 215: | 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