Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100976
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
In-Reply-To: <CAF+90c8qkkSP8RzNFgYnfbxi4d7c9ya6zLTh7xan=2dDgBw8wQ@mail.gmail.com>
Date: Sat, 28 Oct 2017 15:05:39 +0700
Cc: Thomas Punt <tpunt@hotmail.co.uk>,
 Christopher Jones <christopher.jones@oracle.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <4BD31E87-540B-42A3-9823-9FAFD21EEF0A@koalephant.com>
References: <AM4PR0901MB1265667C867226BD7B56E748F9480@AM4PR0901MB1265.eurprd09.prod.outlook.com>
 <0ac37ce7-62f4-7b1c-5b3d-2d2f45190f07@oracle.com>
 <AM4PR0901MB12657CCAAD6D6A825595E851F9470@AM4PR0901MB1265.eurprd09.prod.outlook.com>
 <CAF+90c8qkkSP8RzNFgYnfbxi4d7c9ya6zLTh7xan=2dDgBw8wQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes
From: php-lists@koalephant.com (Stephen Reay)



> On 24 Oct 2017, at 4:58 pm, Nikita Popov <nikita.ppv@gmail.com> wrote:
>=20
> On Tue, Oct 24, 2017 at 11:27 AM, Thomas Punt <tpunt@hotmail.co.uk> =
wrote:
>=20
>> Hi Christopher,
>>=20
>>=20
>>> 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.
>>=20
>> 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).
>=20
>=20
> 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=3D8)? Only 8 (ts=3D4)? Only 4 (ts=3D2)? 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.
>=20
> 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.
>>=20
>>=20
>> Other languages follow these semantics of stripping whitespace from =
new
>> lines
>>=20
>> according to the indentation of the closing marker, such as Elixir =
(normal
>> """ syntax)
>>=20
>> and Ruby (special <<~ syntax).
>>=20
>>=20
>> Thanks,
>>=20
>> Tom
>>=20

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 =
=E2=80=98content=E2=80=99 lines of the heredoc are indented by 8 spaces, =
nothing is removed.

While I agree that features shouldn=E2=80=99t be surprising, I think =
converting tabs to spaces or vice-versa *would* be surprising.

Also, sidenote: =E2=80=98heredoc=E2=80=99 is listed as a spelling =
mistake with a suggestion of =E2=80=98heretic=E2=80=99. Maybe the =
computers know more than we do.

Cheers

Stephen=