[RFC] Flexible Heredoc and Nowdoc Syntaxes

8 years ago by Thomas Punt — view source — reply

unread

Morning internals,

I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more flexible1. Any thoughts?

Thanks,

Tom

8 years ago by Fleshgrinder — view source — reply

unread

Morning internals,

I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more flexible1. Any thoughts?

Thanks,

Tom

Hi Tom!

I love it, definitely should go in. I am sure there are some special
cases that will be discovered in this discussion, but it's an awesome
feature.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Ryan Pallas — view source — reply

unread

Morning internals,

I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more
flexible1. 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 unattached to other characters. In my
experience, people that use these syntaxes (like me) already make sure not
to use something within the body.

Thanks,

Tom

8 years ago by Christopher Jones — view source — reply

unread

Morning internals,

I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more flexible1. Any thoughts?

Thanks,

Tom

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.

Chris

--
http://twitter.com/ghrd

8 years ago by Thomas Punt — view source — reply

unread

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 necessary, but
I included it because it does help with readability when looking at the indentation
level of the heredoc and nowdoc (and subsequently how much whitespace will
be stripped from each line). With respect to the stripping of whitespace, however,
I feel that this is definitely necessary. If it was not stripped, then indenting the
closing token and body will cause a lot of whitespace to prepend every line in
the body of text. This is definitely not desirable, and may cause programmers to
continue to not indent the body of the heredoc/nowdoc, which leads us back to
where we currently are of having indentation of code ruined with such syntaxes.

Other languages follow these semantics of stripping whitespace from new lines

according to the indentation of the closing marker, such as Elixir (normal """ syntax)

and Ruby (special <<~ syntax).

Thanks,

Tom

8 years ago by Nikita Popov — view source — reply

unread

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
necessary, but
I included it because it does help with readability when looking at the
indentation
level of the heredoc and nowdoc (and subsequently how much whitespace will
be stripped from each line).

It's not just a question of readability. You just can't strip a mixed
space/tab indentation unless you specify a tab width. If one line is
indented with two tabs and the other with 16 spaces, what do you strip? All
16 spaces (ts=8)? Only 8 (ts=4)? Only 4 (ts=2)? Unless we want to specify
the One True Tab Width or introduce an ini setting for this, it's not
really possible to handle this in a reasonable way.

With respect to the stripping of whitespace, however,

I feel that this is definitely necessary. If it was not stripped, then
indenting the
closing token and body will cause a lot of whitespace to prepend every
line in
the body of text. This is definitely not desirable, and may cause
programmers to
continue to not indent the body of the heredoc/nowdoc, which leads us back
to
where we currently are of having indentation of code ruined with such
syntaxes.

Other languages follow these semantics of stripping whitespace from new
lines

according to the indentation of the closing marker, such as Elixir (normal
""" syntax)

and Ruby (special <<~ syntax).

Thanks,

Tom

8 years ago by Stephen Reay — view source — reply

unread

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
necessary, but
I included it because it does help with readability when looking at the
indentation
level of the heredoc and nowdoc (and subsequently how much whitespace will
be stripped from each line).

It's not just a question of readability. You just can't strip a mixed
space/tab indentation unless you specify a tab width. If one line is
indented with two tabs and the other with 16 spaces, what do you strip? All
16 spaces (ts=8)? Only 8 (ts=4)? Only 4 (ts=2)? Unless we want to specify
the One True Tab Width or introduce an ini setting for this, it's not
really possible to handle this in a reasonable way.

With respect to the stripping of whitespace, however,

I feel that this is definitely necessary. If it was not stripped, then
indenting the
closing token and body will cause a lot of whitespace to prepend every
line in
the body of text. This is definitely not desirable, and may cause
programmers to
continue to not indent the body of the heredoc/nowdoc, which leads us back
to
where we currently are of having indentation of code ruined with such
syntaxes.

Other languages follow these semantics of stripping whitespace from new
lines

according to the indentation of the closing marker, such as Elixir (normal
""" syntax)

and Ruby (special <<~ syntax).

Thanks,

Tom

Hi Nikita,

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 by 8 spaces, nothing is removed.

While I agree that features shouldn’t be surprising, I think converting tabs to spaces or vice-versa would be surprising.

Also, sidenote: ‘heredoc’ is listed as a spelling mistake with a suggestion of ‘heretic’. Maybe the computers know more than we do.

Cheers

Stephen

8 years ago by Thomas Punt — view source — reply

unread

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 marker should be lined up to), not the indentation level from the start of the line (which may cause developers to indent the body text less to prevent leading whitespace, leading us back to the current situation of having indentation levels ruined by these syntaxes).

this can lead to subtle bugs and annoyances.

I think this clause is a little too exaggerated. Once a developer understands that the closing token guides the indentation level of the body text, then the cause of the change in whitespace should be pretty obvious (if it's not already visually obvious from the fact that they must have broken the indentation level of their own code).

-Tom

8 years ago by Thomas Punt — view source — reply

unread

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 by 8 spaces, nothing is removed.

So let's say the ending marker is indented with [space][tab][space] and the body is indented with [tab][space][tab], by your logic, a [space] and a [tab] should be removed from the body's indentation? Or nothing at all?

The problem with such rules is that they bring more complication to the implementation when it comes down to the finer details. It is far better to simply disallow such nonsense to begin with.

A nice benefit of this (choosing a stricter approach to begin with) is that, should we see advantages to bringing more leniency to the current semantics (such as enabling the mixture of tabs and spaces), then we can enable this later without causing any new BC breaks. Whereas if we introduce a really loose-style syntax to begin with, then we cannot make it stricter later on without introducing new BC breaks.

-Tom

8 years ago by Stephen Reay — view source — reply

unread

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 by 8 spaces, nothing is removed.

So let's say the ending marker is indented with [space][tab][space] and the body is indented with [tab][space][tab], by your logic, a [space] and a [tab] should be removed from the body's indentation? Or nothing at all?

The problem with such rules is that they bring more complication to the implementation when it comes down to the finer details. It is far better to simply disallow such nonsense to begin with.

A nice benefit of this (choosing a stricter approach to begin with) is that, should we see advantages to bringing more leniency to the current semantics (such as enabling the mixture of tabs and spaces), then we can enable this later without causing any new BC breaks. Whereas if we introduce a really loose-style syntax to begin with, then we cannot make it stricter later on without introducing new BC breaks.

-Tom

Hi Tom

In your scenario, nothing at all would be removed. I'd imagine an exact substring anchored to the start-of-line is what's matched for any replacement.

Strict removal like that is the only thing I can see that makes sense - any conversion is likely to lead to developer surprise.

Cheers

Stephen