> On 28 Oct 2017, at 18:17, Thomas Punt wrote:
>
> Hi Stephen,
>
> > I disagree. To me this change would simply mean that the literal exact
> > white-space string preceding the end marker is removed as a prefix from all
> > lines.
> >
> > So if you have an end marker intended by two tab char
Hi Stephen,
> I disagree. To me this change would simply mean that the literal exact
> white-space string preceding the end marker is removed as a prefix from all
> lines.
>
> So if you have an end marker intended by two tab characters, but all the
> ‘content’ lines of the heredoc are indented
> On 24 Oct 2017, at 4:58 pm, Nikita Popov wrote:
>
> On Tue, Oct 24, 2017 at 11:27 AM, Thomas Punt wrote:
>
>> Hi Christopher,
>>
>>
>>> I like the added flexibility in placement of the end token, but I think
>> requiring only tabs or spaces, and stripping whitespace from all
>> {here|now}
Hi,
> If developers accidentally add/subtract leading space from the closing token
> then the whole string changes;
Yes, this is a feature of the chosen semantics. The indentation level of the
body can be chosen based upon the current indentation level of the code (for
which, the closing mar
On 24/10/17 8:27 pm, Thomas Punt wrote:
Hi Christopher,
> I like the added flexibility in placement of the end token, but I think requiring only tabs or spaces, and stripping whitespace from all
{here|now}doc
> lines is error prone and adds unnecessary complexity.
I agree that the require
On Tue, Oct 24, 2017 at 11:27 AM, Thomas Punt wrote:
> Hi Christopher,
>
>
> > I like the added flexibility in placement of the end token, but I think
> requiring only tabs or spaces, and stripping whitespace from all
> {here|now}doc
> > lines is error prone and adds unnecessary complexity.
>
> I
Hi Christopher,
> I like the added flexibility in placement of the end token, but I think
> requiring only tabs or spaces, and stripping whitespace from all {here|now}doc
> lines is error prone and adds unnecessary complexity.
I agree that the requirement for using either tabs or spaces is not
On 13/10/17 8:40 pm, Thomas Punt wrote:
Morning internals,
I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more
flexible[1]. Any thoughts?
Thanks,
Tom
[1]: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes
I like the added flexibility in placement of the en
On Fri, Oct 13, 2017 at 3:40 AM, Thomas Punt wrote:
> Morning internals,
>
>
> I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more
> flexible[1]. Any thoughts?
>
I really like this, and I don't think it's that hard to not use the marker
in the body at the far left of a line u
On 10/13/2017 11:40 AM, Thomas Punt wrote:
> Morning internals,
>
>
> I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more
> flexible[1]. Any thoughts?
>
>
> Thanks,
>
> Tom
>
>
> [1]: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes
>
Hi Tom!
I love it, defin
Morning internals,
I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more
flexible[1]. Any thoughts?
Thanks,
Tom
[1]: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes
11 matches
Mail list logo