Hello everyone,
I'd like to propose adding a new closing tag =?> to the language.
PHP currently removes the newline character immediately following
the closing tag ?>.
With the new closing tag =?>, the code should look like this:
- <?= 1 =?>
- <?= 2 =?>
- <?= 3 =?>
and the results it produces would be:
- 1
- 2
- 3
instead of the following:
- 1- 2- 3
This addition requires only a one-line modification to the lexer and
doesn't break BC. The proposed patch is here.
https://github.com/php/php-src/pull/8708
Before writing an RFC, I would like to hear your input on whether
it's worth tackling.
Thanks!
--
Shinji Igarashi
Hello everyone,
I'd like to propose adding a new closing tag
=?>to the language.PHP currently removes the newline character immediately following
the closing tag?>.
Personal opinion, seems like a classic sledgehammer on a nut proposal. I
actually prefer the <?= $whatever . PHP_EOL ?> or ."\n" notation since it
makes it explicitly clear what you're intending to output and keeps it
within the control of the PHP code block. Alternatively it's also enough in
the case of plain text or wherever else this matters to you to just add a
space after the closing tag before the newline (granted there may be niche
situations where this is undesirable).
It's not a breaking change for any existing code, at least, but for me I
still don't see enough of a benefit that I'd think it was worth adding to
the language, as any new syntax creates the potential for confusion and
user error. Is this a big enough problem to be worth any change at all? In
over 15 years of writing PHP, I've never once had a situation where closing
tag newline elision has been an issue.
-Dave
With the new closing tag
=?>, the code should look like this:- <?= 1 =?> - <?= 2 =?> - <?= 3 =?>and the results it produces would be:
- 1 - 2 - 3instead of the following:
- 1- 2- 3This addition requires only a one-line modification to the lexer and
doesn't break BC. The proposed patch is here.
https://github.com/php/php-src/pull/8708Before writing an RFC, I would like to hear your input on whether
it's worth tackling.Thanks!
--
Shinji Igarashi--
To unsubscribe, visit: https://www.php.net/unsub.php
<?= $whatever .
PHP_EOL?> or ."\n"
Yeah, adding an explicit newline character is a workaround for this.
However, what if that output content were moved to a location other
than the end of a line when editing the template? It would be
necessary to remove the extra newline character each time
they move from the end of a line.
With this new closing tag, the behavior of the output block can be
position-independent.
Your concerns are valid and I agree that this is a small difference.
What I am not sure about is how many people want this small
difference, so I'm asking around in some parts of the community.
Thanks for your feedback!
--
Shinji Igarashi
2022年6月6日(月) 6:31 David Gebler davidgebler@gmail.com:
Hello everyone,
I'd like to propose adding a new closing tag
=?>to the language.PHP currently removes the newline character immediately following
the closing tag?>.Personal opinion, seems like a classic sledgehammer on a nut proposal. I actually prefer the <?= $whatever .
PHP_EOL?> or ."\n" notation since it makes it explicitly clear what you're intending to output and keeps it within the control of the PHP code block. Alternatively it's also enough in the case of plain text or wherever else this matters to you to just add a space after the closing tag before the newline (granted there may be niche situations where this is undesirable).It's not a breaking change for any existing code, at least, but for me I still don't see enough of a benefit that I'd think it was worth adding to the language, as any new syntax creates the potential for confusion and user error. Is this a big enough problem to be worth any change at all? In over 15 years of writing PHP, I've never once had a situation where closing tag newline elision has been an issue.
-Dave
With the new closing tag
=?>, the code should look like this:- <?= 1 =?> - <?= 2 =?> - <?= 3 =?>and the results it produces would be:
- 1 - 2 - 3instead of the following:
- 1- 2- 3This addition requires only a one-line modification to the lexer and
doesn't break BC. The proposed patch is here.
https://github.com/php/php-src/pull/8708Before writing an RFC, I would like to hear your input on whether
it's worth tackling.Thanks!
--
Shinji Igarashi--
To unsubscribe, visit: https://www.php.net/unsub.php
I'd like to propose adding a new closing tag
=?>to the language.PHP currently removes the newline character immediately following
the closing tag?>.
So we would have 4 possible combinations that developers could apply in
their code, two existing open/close settings
<?php echo 1 ?>
<?= 1 ?>
and two new combinations, the first you explain
<?= 1 =?>
but also
<?php echo 1 =?>
What should PHP do when it encounters this combination of
opening/closing tags?
--
Mark Baker
|. \ -3
|J/ PHP |
|| | __ |
|| |m| |m|
I LOVE PHP
Hello!
<?php echo 1 =?>
It should behave exactly the same as the existing closing tag,
except that it does not erase the trailing newline character.
Thanks!
--
Shinji Igarashi
2022年6月6日(月) 6:54 Mark Baker mark@demon-angel.eu:
I'd like to propose adding a new closing tag
=?>to the language.PHP currently removes the newline character immediately following
the closing tag?>.So we would have 4 possible combinations that developers could apply in
their code, two existing open/close settings<?php echo 1 ?>
<?= 1 ?>
and two new combinations, the first you explain
<?= 1 =?>
but also
<?php echo 1 =?>
What should PHP do when it encounters this combination of
opening/closing tags?--
Mark Baker
|. \ -3
|J/ PHP |
|| | __ |
|| |m| |m|I LOVE PHP
--
To unsubscribe, visit: https://www.php.net/unsub.php
Hello!
I asked for opinions on reddit also.
https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/
Popularity on reddit and acceptance by people with voting rights on
internals can be different, but it seems that, at least in its current
form, this proposal would have a hard time winning the vote.
Until I can come up with a stronger persuasion or a nicer way of
doing this, I don't feel it has a chance to win, so I'm withdrawing
from this proposal for now and going to work on something else.
Thanks for taking a look!
--
Shinji Igarashi
2022年6月5日(日) 17:23 shinji igarashi sji@sj-i.dev:
Hello everyone,
I'd like to propose adding a new closing tag
=?>to the language.PHP currently removes the newline character immediately following
the closing tag?>.With the new closing tag
=?>, the code should look like this:- <?= 1 =?> - <?= 2 =?> - <?= 3 =?>and the results it produces would be:
- 1 - 2 - 3instead of the following:
- 1- 2- 3This addition requires only a one-line modification to the lexer and
doesn't break BC. The proposed patch is here.
https://github.com/php/php-src/pull/8708Before writing an RFC, I would like to hear your input on whether
it's worth tackling.Thanks!
--
Shinji Igarashi
On Mon, Jun 6, 2022 at 6:47 PM shinji igarashi
shinji.igarashi@gmail.com wrote:
Hello!
I asked for opinions on reddit also.
https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/Popularity on reddit and acceptance by people with voting rights on
internals can be different, but it seems that, at least in its current
form, this proposal would have a hard time winning the vote.Until I can come up with a stronger persuasion or a nicer way of
doing this, I don't feel it has a chance to win, so I'm withdrawing
from this proposal for now and going to work on something else.Thanks for taking a look!
--
Shinji Igarashi2022年6月5日(日) 17:23 shinji igarashi sji@sj-i.dev:
Hello everyone,
I'd like to propose adding a new closing tag
=?>to the language.PHP currently removes the newline character immediately following
the closing tag?>.With the new closing tag
=?>, the code should look like this:- <?= 1 =?> - <?= 2 =?> - <?= 3 =?>and the results it produces would be:
- 1 - 2 - 3instead of the following:
- 1- 2- 3This addition requires only a one-line modification to the lexer and
doesn't break BC. The proposed patch is here.
https://github.com/php/php-src/pull/8708Before writing an RFC, I would like to hear your input on whether
it's worth tackling.Thanks!
--
Shinji Igarashi--
To unsubscribe, visit: https://www.php.net/unsub.php
FWIW, I think it makes a lot of sense, having used golang's template
language (not everyone is generating HTML with PHP). I think you may
just be dealing with a vocal minority and it would be worth putting to
an actual vote. Even if it fails, we'll learn something the next time
someone wants to change something like this.
Hello!
I asked for opinions on reddit also.
https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/Popularity on reddit and acceptance by people with voting rights on internals can be different, but it seems that, at least in its current form, this proposal would have a hard time winning the vote.
FWIW, I think it makes a lot of sense, having used golang's template language (not everyone is generating HTML with PHP). I think you may just be dealing with a vocal minority and it would be worth putting to an actual vote. Even if it fails, we'll learn something the next time someone wants to change something like this.
So long as it's not likely to cause problems, I think <?= $var =?> is a bit easier to read than
-
<?= $var .PHP_EOL?> -
<?= $var . "\n" ?> -
<?php echo $var . "\n" ?>
It's of things that probably won't have strong supporters, but might be nice to have (I find some junior developers question why their HTML output can be a bit messy, not that it's really a problem, but it's there).
Craig
On Tue, Jun 7, 2022 at 10:27 AM Robert Landers landers.robert@gmail.com
wrote:
FWIW, I think it makes a lot of sense, having used golang's template
language (not everyone is generating HTML with PHP). I think you may
just be dealing with a vocal minority and it would be worth putting to
an actual vote. Even if it fails, we'll learn something the next time
someone wants to change something like this.
While my gut response for the new end tag is in the "no" column, I do
wonder if we can accommodate "non-html" scenarios in a broader (maybe more
palatable?) way by assuming that if you want the newline to be respected on
one line, you probably want it that way for the whole file.
<?php
declare(ignore_newline_after_close_tag=false); // defaults to true, i.e
existing behavior
This would avoid any new syntax rules, but still provide the ability for
php-as-template-engine to behave in the user's preferred mode.
-Sara
<?php
declare(ignore_newline_after_close_tag=false); // defaults to true, i.e
existing behavior
This would avoid any new syntax rules, but still provide the ability for
php-as-template-engine to behave in the user's preferred mode.
I thought it's a consensus on internal that we should avoid such runtime configuration that can affect code behaviour, otherwise we have a long list to check when we debug or ask for help. Yeah I know we already have a lot, and it's a easy and straightforward solution to add a switch for this kind of issues, but we should be careful to introduce a new one. (Personlly I was a supporter for runtime configuration as well, but I'm not able to convince myself to ignore or defeat that argument.)
Regards,
CHU Zhaowei
<?php
declare(ignore_newline_after_close_tag=false); // defaults to true, i.e
existing behaviorThis would avoid any new syntax rules, but still provide the ability for
php-as-template-engine to behave in the user's preferred mode.I thought it's a consensus on internal that we should avoid such runtime
configuration that can affect code behaviour, otherwise we have a long list
to check when we debug or ask for help. Yeah I know we already have a lot,
and it's a easy and straightforward solution to add a switch for this kind
of issues, but we should be careful to introduce a new one. (Personlly I
was a supporter for runtime configuration as well, but I'm not able to
convince myself to ignore or defeat that argument.)
That would be a top-of-file declare, not a runtime configuration.
Le 8 juin 2022 à 05:34, Sara Golemon pollita@php.net a écrit :
<?php
declare(ignore_newline_after_close_tag=false); // defaults to true, i.e
existing behaviorThis would avoid any new syntax rules, but still provide the ability for
php-as-template-engine to behave in the user's preferred mode.
No, because the user’s preferred mode is not a global one, it is a local one. You do not want to keep newlines in the following situation:
* line 1
<?php if ($foo): ?>
* line 2
* line 3
<?php endif; ?>
* line 4
With a global switch, not only you have failed to solve the real problem (doing the Right Thing with newlines), but also you have created another one (looking at the top of the file in order to understand the code). You have the worst of both world.
—Claude
Le 8 juin 2022 à 05:34, Sara Golemon pollita@php.net a écrit :
<?php
declare(ignore_newline_after_close_tag=false); // defaults to true, i.e
existing behaviorThis would avoid any new syntax rules, but still provide the ability for
php-as-template-engine to behave in the user's preferred mode.No, because the user’s preferred mode is not a global one, it is a local
one. You do not want to keep newlines in the following situation:* line 1 <?php if ($foo): ?> * line 2 * line 3 <?php endif; ?> * line 4With a global switch, not only you have failed to solve the real problem
(doing the Right Thing with newlines), but also you have created another
one (looking at the top of the file in order to understand the code). You
have the worst of both world.
Declare statements shouldn't have any impact outside of the file in which
they appear. Declaring strict types doesn't force other classes that
interact with the defined class to also use strict types. A declare to
change how newlines after closing tags are handled within a single file
forces anything that uses the classes/functions defined in that file to
know that it handles them in a possibly different ways.
I personally don't see a need for a new closing tag. I'm not usually swayed
by the "it adds confusion to the language" and would be against removing
such a tag if it existed and that was the reason for removing it. However,
I do think it's something to consider when adding something new to the
language. In this case, I don't think the positives outweigh the negatives,
especially in light of the fact it's really easy to accomplish this without
changes.
—Claude
To unsubscribe, visit: https://www.php.net/unsub.php
--
Chase Peeler
chasepeeler@gmail.com
Declare statements shouldn't have any impact outside of the file in which
they appear. Declaring strict types doesn't force other classes that
interact with the defined class to also use strict types. A declare to
change how newlines after closing tags are handled within a single file
forces anything that uses the classes/functions defined in that file to
know that it handles them in a possibly different ways.
Indeed (via includes)... Also consider this hypothetical example:
- 0
<?php foreach([1, 2, 3] as $item): ?>
- <?= $item =?>
<?php endforeach; ?>
- 4
Note the use of both ?> and =?> within the same file; a declare
would not allow that.
I personally don't see a need for a new closing tag. I'm not usually swayed
by the "it adds confusion to the language" and would be against removing
such a tag if it existed and that was the reason for removing it. However,
I do think it's something to consider when adding something new to the
language. In this case, I don't think the positives outweigh the negatives,
especially in light of the fact it's really easy to accomplish this without
changes.
I personally am generally in favor of removing "magic" stuff (even if
this isn't exactly proposing that but to add a "straightforward"
alternative).
Other example, consider starting from this:
- first
- foo bar
- last
Now if you want to "variablize" the foo part, just change it to e.g.
<?= $foo ?>; but for bar you have to remember and write e.g. <?= $bar, PHP_EOL ?> (or add a blank line after it [or a trailing
space... no, please don't]), only because it happens to be at the end
of a line (and don't forget to re-change it if you later append a
qux)...
PS: An[other] argument against could be something like "please don't
add more things encouraging the use of PHP as a templating engine
(unsafe etc.)", but the main target is non-HTML (e.g. Markdown or
raw text) templates.
--
Guilliam Xavier
declare(ignore_newline_after_close_tag=false);
Thanks for coming up with another idea!
As others have already pointed out, disabling the closing tag from
eating trailing newline throughout the file would be inconvenient if
we want to use control statements in the template.
However, we currently only have one closing tag, but we already
have two opening tags. So, for example, if we use declare to disable
the newline eating only when closing a PHP block started with `<?=',
it can produce the desired output.
<?php declare(ignore_newline_after_closing_short_tag=false) ?>
<?php foreach ([1, 2, 3] as $item): ?>
- <? = $item ?>
<?php endforeach ?>
I'm honestly not sure if adding a declare switch is better received
than a new closing tag, though.
Thanks!
--
Shinji Igarashi
2022年6月8日(水) 12:34 Sara Golemon pollita@php.net:
FWIW, I think it makes a lot of sense, having used golang's template
language (not everyone is generating HTML with PHP). I think you may
just be dealing with a vocal minority and it would be worth putting to
an actual vote. Even if it fails, we'll learn something the next time
someone wants to change something like this.While my gut response for the new end tag is in the "no" column, I do wonder if we can accommodate "non-html" scenarios in a broader (maybe more palatable?) way by assuming that if you want the newline to be respected on one line, you probably want it that way for the whole file.
<?php
declare(ignore_newline_after_close_tag=false); // defaults to true, i.e existing behaviorThis would avoid any new syntax rules, but still provide the ability for php-as-template-engine to behave in the user's preferred mode.
-Sara
declare(ignore_newline_after_close_tag=false);
Thanks for coming up with another idea!
As others have already pointed out, disabling the closing tag from
eating trailing newline throughout the file would be inconvenient if
we want to use control statements in the template.However, we currently only have one closing tag, but we already
have two opening tags. So, for example, if we use declare to disable
the newline eating only when closing a PHP block started with `<?=',
it can produce the desired output.<?php declare(ignore_newline_after_closing_short_tag=false) ?>
<?php foreach ([1, 2, 3] as $item): ?>
- <? = $item ?>
<?php endforeach ?>I'm honestly not sure if adding a declare switch is better received
than a new closing tag, though.Thanks!
--
Shinji Igarashi2022年6月8日(水) 12:34 Sara Golemon pollita@php.net:
On Tue, Jun 7, 2022 at 10:27 AM Robert Landers landers.robert@gmail.com
wrote:FWIW, I think it makes a lot of sense, having used golang's template
language (not everyone is generating HTML with PHP). I think you may
just be dealing with a vocal minority and it would be worth putting to
an actual vote. Even if it fails, we'll learn something the next time
someone wants to change something like this.While my gut response for the new end tag is in the "no" column, I do
wonder if we can accommodate "non-html" scenarios in a broader (maybe more
palatable?) way by assuming that if you want the newline to be respected on
one line, you probably want it that way for the whole file.<?php
declare(ignore_newline_after_close_tag=false); // defaults to true, i.e
existing behaviorThis would avoid any new syntax rules, but still provide the ability for
php-as-template-engine to behave in the user's preferred mode.-Sara
--
To unsubscribe, visit: https://www.php.net/unsub.php
I'm just adding a few cents into this discussion for some inspiration. If
I'm not mistaken, the Twig template engine, for example, has such a
difference integrated in the output tag and the statement tag. The
statement tag ({% %}) behaves as PHP tag, it removes the newline character.
The outputting tag ({{ }}) adds a newline at the end.
See this: https://twigfiddle.com/pto9qx
More info about this here:
https://twig.symfony.com/doc/3.x/templates.html#whitespace-control
So, it is actually important to have such functionality in templates.
Hello!
I think you may just be dealing with a vocal minority and it would be worth putting to
an actual vote. Even if it fails, we'll learn something the next time
someone wants to change something like this.
Thanks for the feedback!
In my experience over the years of watching internals, many
controversial language changes do not survive the voting. Two
Yeses are balanced against one No, so there needs to be
overwhelming agreement.
Surely it could at least be said that even if it fails, it is easier for
someone who later comes up with a similar idea to find past efforts
if the RFC is drafted and the results of the voting are there.
However, the July 19 Feature Freeze for 8.2 is approaching!
So I'll try to write an RFC on this proposal later for 8.3.
For now, I will look at the interpreter code and see if I can come up
with another proposal and its implementation that is a little less
controversial (like constants on traits) until the 8.2 effective deadlines.
My ability to write English is very limited, so probably I cannot
proceed with multiple proposals in parallel.
Thanks!
--
Shinji Igarashi
2022年6月8日(水) 0:27 Robert Landers landers.robert@gmail.com:
On Mon, Jun 6, 2022 at 6:47 PM shinji igarashi
shinji.igarashi@gmail.com wrote:Hello!
I asked for opinions on reddit also.
https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/Popularity on reddit and acceptance by people with voting rights on
internals can be different, but it seems that, at least in its current
form, this proposal would have a hard time winning the vote.Until I can come up with a stronger persuasion or a nicer way of
doing this, I don't feel it has a chance to win, so I'm withdrawing
from this proposal for now and going to work on something else.Thanks for taking a look!
--
Shinji Igarashi2022年6月5日(日) 17:23 shinji igarashi sji@sj-i.dev:
Hello everyone,
I'd like to propose adding a new closing tag
=?>to the language.PHP currently removes the newline character immediately following
the closing tag?>.With the new closing tag
=?>, the code should look like this:- <?= 1 =?> - <?= 2 =?> - <?= 3 =?>and the results it produces would be:
- 1 - 2 - 3instead of the following:
- 1- 2- 3This addition requires only a one-line modification to the lexer and
doesn't break BC. The proposed patch is here.
https://github.com/php/php-src/pull/8708Before writing an RFC, I would like to hear your input on whether
it's worth tackling.Thanks!
--
Shinji Igarashi--
To unsubscribe, visit: https://www.php.net/unsub.php
FWIW, I think it makes a lot of sense, having used golang's template
language (not everyone is generating HTML with PHP). I think you may
just be dealing with a vocal minority and it would be worth putting to
an actual vote. Even if it fails, we'll learn something the next time
someone wants to change something like this.
Hi,
https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/
Thanks for proposing! this "feature" bothered me more than once...
Maybe just 2 days (of internals and Reddit feedback) is a bit early to
"give up" (but I won't blame you either).
FWIW, the Twig templating engine has distinct delimiters for output
({{ ... }}) and control ({% ... %}), and the former does not eat
newline; for the latter you can use ~%}
(https://twigfiddle.com/54daye), and there are other "whitespace
control" options
(https://twig.symfony.com/doc/3.x/templates.html#whitespace-control).
For PHP, if we could ignore BC, I would rather have ?> not eat
newline, and add an optional way to do it; but we can't, so I guess
the opposite (e.g. your =?>) is the best we could hope for.
Regards,
--
Guilliam Xavier
Hi, thanks for supporting this!
Maybe just 2 days (of internals and Reddit feedback) is a bit early to
"give up"
I kinda thought so too after I declared defeat, but...
The Feature Freeze for 8.2 is July 19!
The RFC process requires two weeks each for discussion and voting.
If we want to add something good to 8.2, we have to draft the RFC
and start discussing it on internals by June 21 at the latest. So I may
be a bit impatient, yeah.
Other template engines, such as twig or ERB, often have flexible ways
of handling whitespace and newline characters around tags. I'm not
trying to make PHP more sophisticated to compete with them, but it
seemed that just handling trailing newlines would be easy to implement,
doesn't complicate the engine, so I proposed this.
I am encouraged by the supportive people and will try to work on it
again when I have more time to use.
Thanks!
--
Shinji Igarashi
2022年6月8日(水) 21:48 Guilliam Xavier guilliam.xavier@gmail.com:
Hi,
https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/
Thanks for proposing! this "feature" bothered me more than once...
Maybe just 2 days (of internals and Reddit feedback) is a bit early to
"give up" (but I won't blame you either).FWIW, the Twig templating engine has distinct delimiters for output
({{ ... }}) and control ({% ... %}), and the former does not eat
newline; for the latter you can use ~%}
(https://twigfiddle.com/54daye), and there are other "whitespace
control" options
(https://twig.symfony.com/doc/3.x/templates.html#whitespace-control).For PHP, if we could ignore BC, I would rather have ?> not eat
newline, and add an optional way to do it; but we can't, so I guess
the opposite (e.g. your =?>) is the best we could hope for.Regards,
--
Guilliam Xavier