- http://www.slideshare.net/thinkphp/php-53-and-php-6-a-look-ahead
- http://wiki.claroline.net/index.php/Coding_Rules
If it's not, then what are your thoughts on using ASP/JSP-style tags
(<%), and perhaps making them the recommended option?
I've just read through an old (and rather long) thread* regarding
short_open_tag, and no one mentioned this as an option.
<%= $article->title; %>
It's short, and it doesn't conflict with XML.
Glen.
- php-dev@lists.php.net/msg43002.html" rel="nofollow" target="_blank">http://www.mail-archive.com/php-dev@lists.php.net/msg43002.html
Glen wrote:
It's short, and it doesn't conflict with XML.
I have to say, I don't understand all the hate on short_open_tag. So
what if it "conflicts" with XML? PHP is not XML. If you use an XML
construct in your PHP, escape it. PHP can generate a lot of other
languages, too -- should every construct from these languages be
forbidden in PHP as well?
Jeremy
2009/4/13 Jeremy jeremy@pinacol.com:
Glen wrote:
It's short, and it doesn't conflict with XML.
I have to say, I don't understand all the hate on short_open_tag. So what
if it "conflicts" with XML? PHP is not XML. If you use an XML construct in
your PHP, escape it. PHP can generate a lot of other languages, too --
should every construct from these languages be forbidden in PHP as well?
Thats because with short_open_tags on, you need to use:
<?php echo('<?xml ... ?>'); ?>
to print the XML declaring, with short open tags, the xml part is
considered a piece of code, which causes a syntax error
Jeremy
--
--
Kalle Sommer Nielsen
kalle@php.net
I think that's what he meant by "escape it". I haven't used short_open_tags
myself much, but as I've been exploring templating options I like it for
outputting variables.
James Logsdon
2009/4/13 Jeremy jeremy@pinacol.com:
Glen wrote:
It's short, and it doesn't conflict with XML.
I have to say, I don't understand all the hate on short_open_tag. So
what
if it "conflicts" with XML? PHP is not XML. If you use an XML construct
in
your PHP, escape it. PHP can generate a lot of other languages, too --
should every construct from these languages be forbidden in PHP as well?Thats because with short_open_tags on, you need to use:
<?php echo('<?xml ... ?>'); ?>to print the XML declaring, with short open tags, the xml part is
considered a piece of code, which causes a syntax errorJeremy
--
--
Kalle Sommer Nielsen
kalle@php.net
Hi!
Thats because with short_open_tags on, you need to use:
<?php echo('<?xml ... ?>'); ?>
It's a pretty small use case (that's a problem only if you have xml
documents which has to have php code which has to be inlined) and as you
see, can be easily handled. I think that should not make whole very
useful syntax deprecated.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
It's a pretty small use case (that's a problem only if you have xml
documents which has to have php code which has to be inlined) and as you
see, can be easily handled. I think that should not make whole very useful
syntax deprecated.
+1
One of the reason's for PHP's success IMO is the ease of creating templates
with it. Forcing everyone to write <?php echo $var ?> every time just just
so that you don't have to write <?php echo '<?...' once is not a fair trade
off. My $.02.
Mike.
I'm not suggesting anyone be forced to do anything.
But:
<?xml version="1.0" encoding="UTF-8" ?>
...
<%= $this->that; %>
Looks neater than:
<?= '<?xml version="1.0" encoding="UTF-8" ?>'; ?>
...
<?= $this->that; ?>
Hence my suggestion.
Glen.
Mike Panchenko wrote:
It's a pretty small use case (that's a problem only if you have xml
documents which has to have php code which has to be inlined) and as you
see, can be easily handled. I think that should not make whole very useful
syntax deprecated.+1
One of the reason's for PHP's success IMO is the ease of creating templates
with it. Forcing everyone to write <?php echo $var ?> every time just just
so that you don't have to write <?php echo '<?...' once is not a fair trade
off. My $.02.Mike.
Hi!
Thats because with short_open_tags on, you need to use:
<?php echo('<?xml ... ?>'); ?>It's a pretty small use case (that's a problem only if you have xml
documents which has to have php code which has to be inlined) and as
you see, can be easily handled. I think that should not make whole
very useful syntax deprecated.
I think the parser should look ahead and check for something like :
/<?(php|[\w])
(either <?php or <? + linebreaks/whitespace).
Evert
Right, but at the moment something like:
<?$this->that;?>
... works. i.e. no whitespace after the opening tag.
Changing this would most likely break a fair amount of code.
Glen.
Evert | Filemobile wrote:
Hi!
Thats because with short_open_tags on, you need to use:
<?php echo('<?xml ... ?>'); ?>It's a pretty small use case (that's a problem only if you have xml
documents which has to have php code which has to be inlined) and as
you see, can be easily handled. I think that should not make whole
very useful syntax deprecated.I think the parser should look ahead and check for something like :
/<?(php|[\w])
(either <?php or <? + linebreaks/whitespace).
Evert
PLEASE, let the dead horse be!
--Jani
Glen wrote:
Right, but at the moment something like:
<?$this->that;?>
.. works. i.e. no whitespace after the opening tag.
Changing this would most likely break a fair amount of code.
Glen.
Evert | Filemobile wrote:
Hi!
Thats because with short_open_tags on, you need to use:
<?php echo('<?xml ... ?>'); ?>
It's a pretty small use case (that's a problem only if you have xml
documents which has to have php code which has to be inlined) and as
you see, can be easily handled. I think that should not make whole
very useful syntax deprecated.
I think the parser should look ahead and check for something like :/<?(php|[\w])
(either <?php or <? + linebreaks/whitespace).
Evert
Which horse are you referring to exactly?
Jani Taskinen wrote:
PLEASE, let the dead horse be!
--Jani
Glen wrote:
Right, but at the moment something like:
<?$this->that;?>
.. works. i.e. no whitespace after the opening tag.
Changing this would most likely break a fair amount of code.
Glen.
Evert | Filemobile wrote:
Hi!
Thats because with short_open_tags on, you need to use:
<?php echo('<?xml ... ?>'); ?>
It's a pretty small use case (that's a problem only if you have xml
documents which has to have php code which has to be inlined) and as
you see, can be easily handled. I think that should not make whole
very useful syntax deprecated.
I think the parser should look ahead and check for something like :/<?(php|[\w])
(either <?php or <? + linebreaks/whitespace).
Evert
Today this topic may be the cloudiest and most heated in all of PHP.
Here's the factual history of our poor little short_open_tag directive:
php.ini values : short_open_tag
PHP 4, 5_0
- Default behaviour : on
- php.ini-dist : on
- php.ini-recommended : on
PHP 5_1, 5_2:
- Default behaviour : on
- php.ini-dist : on
- php.ini-recommended : off
PHP 5_3:
- Default behaviour : on
- php.ini-development : off
- php.ini-production : off
php.ini descriptions : short_open_tag
In 5_2 our reason for discouraging it is:
; - short_open_tag = Off [Portability]
; Using short tags is discouraged when developing code meant for
redistribution
; since short tags may not be supported on the target server.
; Allow the <? tag. Otherwise, only <?php and <script> tags are
recognized.
; NOTE: Using short tags should be avoided when developing
applications or
; libraries that are meant for redistribution, or deployment on PHP
; servers which are not under your control, because short tags may not
; be supported on the target server. For portable, redistributable code,
; be sure not to use short tags.
In 5_3 it's:
; This directive determines whether or not PHP will recognize code
between
; <? and ?> tags as PHP source which should be processed as such. It's
been
; recommended for several years that you not use the short tag "short
cut" and
; instead to use the full <?php and ?> tag combination. With the wide
spread use
; of XML and use of these tags by other languages, the server can
become easily
; confused and end up parsing the wrong code in the wrong context. But
because
; this short cut has been a feature for such a long time, it's
currently still
; supported for backwards compatibility, but we recommend you don't
use them.
This history strongly suggests PHP is hoping and subtly forcing the
world to stop using this directive, and although it's not deprecated
the wording and treatment makes it feel it could be any day now. This
situation must be clarified before 5_3 is released, and will likely
require our BDFL to do it.
In related news, what came of this RFC? It still says "Under
Discussion":
Regards,
Philip
Hey Guys,
Whenever I start an XHTML document, I do escape it this way:
<<?="?"?>xml version="1.0" encoding="utf-8"?>
Where the <? part will be the output by PHP.
<?="?"?> equals <? print "?" ?> equals <?php print "?" ?>
So, please do not deprecate it - because it's important for me :$
Thanks,
(c) Kenan Sulayman
Freelance Designer and Programmer
Life's Live Poetry
2009/4/14 Philip Olson philip@roshambo.org
Today this topic may be the cloudiest and most heated in all of PHP. Here's
the factual history of our poor little short_open_tag directive:
php.ini values : short_open_tag
PHP 4, 5_0
- Default behaviour : on
- php.ini-dist : on
- php.ini-recommended : on
PHP 5_1, 5_2:
- Default behaviour : on
- php.ini-dist : on
- php.ini-recommended : off
PHP 5_3:
- Default behaviour : on
- php.ini-development : off
- php.ini-production : off
php.ini descriptions : short_open_tag
In 5_2 our reason for discouraging it is:
; - short_open_tag = Off [Portability]
; Using short tags is discouraged when developing code meant for
redistribution
; since short tags may not be supported on the target server.
; Allow the <? tag. Otherwise, only <?php and <script> tags are recognized.
; NOTE: Using short tags should be avoided when developing applications or
; libraries that are meant for redistribution, or deployment on PHP
; servers which are not under your control, because short tags may not
; be supported on the target server. For portable, redistributable code,
; be sure not to use short tags.In 5_3 it's:
; This directive determines whether or not PHP will recognize code between
; <? and ?> tags as PHP source which should be processed as such. It's been
; recommended for several years that you not use the short tag "short cut"
and
; instead to use the full <?php and ?> tag combination. With the wide
spread use
; of XML and use of these tags by other languages, the server can become
easily
; confused and end up parsing the wrong code in the wrong context. But
because
; this short cut has been a feature for such a long time, it's currently
still
; supported for backwards compatibility, but we recommend you don't use
them.
This history strongly suggests PHP is hoping and subtly forcing the world
to stop using this directive, and although it's not deprecated the wording
and treatment makes it feel it could be any day now. This situation must be
clarified before 5_3 is released, and will likely require our BDFL to do it.In related news, what came of this RFC? It still says "Under Discussion":
Regards,
Philip
Hi,
A vote in support of short tags, although last time I checked they were not
removed in PHP6 (and I hate to see this brought up once more).
On top of that, the supposed XML conflict argument is not fully thought
through, since full PHP tags are not XML compliant either:
<?php echo "?>"; ?>
In the above example, XML parsers would do this:
Processing directive: <?php echo "?>
Text node: "; ?
Parse error: >
As you see, it's a much simpler world when we realize PHP was never supposed
to be XML in the first place. However it was supposed to be a preprocessing
templating engine, and so we need to keep it optimized for that.
Regards,
Stan Vassilev
Stan Vassilev | FM wrote:
Hi,
A vote in support of short tags, although last time I checked they were
not removed in PHP6 (and I hate to see this brought up once more).
On top of that, the supposed XML conflict argument is not fully thought
through, since full PHP tags are not XML compliant either:<?php echo "?>"; ?>
In the above example, XML parsers would do this:
Processing directive: <?php echo "?>
Text node: "; ?
Parse error: >As you see, it's a much simpler world when we realize PHP was never
supposed to be XML in the first place. However it was supposed to be a
preprocessing templating engine, and so we need to keep it optimized for
that.
Which is one of the reasons we decided not to remove them in PHP 6.
-Rasmus
I didn't say PHP tags were valid XML. I said short_open_tag conflicts
with <?xml and other PIs.
<% is not valid XML either, but it doesn't conflict with processing
instructions.
Glen.
Stan Vassilev | FM wrote:
Hi,
A vote in support of short tags, although last time I checked they
were not removed in PHP6 (and I hate to see this brought up once more).
On top of that, the supposed XML conflict argument is not fully
thought through, since full PHP tags are not XML compliant either:<?php echo "?>"; ?>
In the above example, XML parsers would do this:
Processing directive: <?php echo "?>
Text node: "; ?
Parse error: >As you see, it's a much simpler world when we realize PHP was never
supposed to be XML in the first place. However it was supposed to be a
preprocessing templating engine, and so we need to keep it optimized
for that.Regards,
Stan Vassilev
I didn't say PHP tags were valid XML. I said short_open_tag conflicts
with <?xml and other PIs.<% is not valid XML either, but it doesn't conflict with processing
instructions.Glen.
Hello Glen,
posting to mailing-lists is not a speed race so think about your answer
before sending it. There should be no need to send four emails in a row as
you can easily answer multiple persons / arguments in a single post. This
discussion belongs to internals list anymore, so please move it to
php-general mailing list.
CCing the correct list in this mail.
--
Mikko Koppanen
Why such a complicated-looking thing (that breaks syntax-highlighting,
at least in my IDE), when you can just use:
<?= '<?xml version="1.0" encoding="UTF-8" ?>'; ?>
Or turn short_open_tag off (and asp_tags on), and use:
<?xml version="1.0" encoding="UTF-8" ?>
...
<%= $this->that; %>
Glen.
Kenan Sulayman wrote:
Hey Guys,
Whenever I start an XHTML document, I do escape it this way:
<<?="?"?>xml version="1.0" encoding="utf-8"?>
Where the <? part will be the output by PHP.
<?="?"?> equals <? print "?" ?> equals <?php print "?" ?>
So, please do not deprecate it - because it's important for me :$
Thanks,
(c) Kenan Sulayman
Freelance Designer and ProgrammerLife's Live Poetry
2009/4/14 Philip Olson philip@roshambo.org
Today this topic may be the cloudiest and most heated in all of PHP. Here's
the factual history of our poor little short_open_tag directive:
php.ini values : short_open_tag
PHP 4, 5_0
- Default behaviour : on
- php.ini-dist : on
- php.ini-recommended : on
PHP 5_1, 5_2:
- Default behaviour : on
- php.ini-dist : on
- php.ini-recommended : off
PHP 5_3:
- Default behaviour : on
- php.ini-development : off
- php.ini-production : off
php.ini descriptions : short_open_tag
In 5_2 our reason for discouraging it is:
; - short_open_tag = Off [Portability]
; Using short tags is discouraged when developing code meant for
redistribution
; since short tags may not be supported on the target server.
; Allow the <? tag. Otherwise, only <?php and <script> tags are recognized.
; NOTE: Using short tags should be avoided when developing applications or
; libraries that are meant for redistribution, or deployment on PHP
; servers which are not under your control, because short tags may not
; be supported on the target server. For portable, redistributable code,
; be sure not to use short tags.In 5_3 it's:
; This directive determines whether or not PHP will recognize code between
; <? and ?> tags as PHP source which should be processed as such. It's been
; recommended for several years that you not use the short tag "short cut"
and
; instead to use the full <?php and ?> tag combination. With the wide
spread use
; of XML and use of these tags by other languages, the server can become
easily
; confused and end up parsing the wrong code in the wrong context. But
because
; this short cut has been a feature for such a long time, it's currently
still
; supported for backwards compatibility, but we recommend you don't use
them.
This history strongly suggests PHP is hoping and subtly forcing the world
to stop using this directive, and although it's not deprecated the wording
and treatment makes it feel it could be any day now. This situation must be
clarified before 5_3 is released, and will likely require our BDFL to do it.In related news, what came of this RFC? It still says "Under Discussion":
Regards,
Philip
Thanks for the information, Philip.
I hereby summon the BDFL ... erm, no pressure. :-)
I really think ASP/JSP tags could be the answer.
Glen.
Philip Olson wrote:
Today this topic may be the cloudiest and most heated in all of PHP.
Here's the factual history of our poor little short_open_tag directive:
php.ini values : short_open_tag
PHP 4, 5_0
- Default behaviour : on
- php.ini-dist : on
- php.ini-recommended : on
PHP 5_1, 5_2:
- Default behaviour : on
- php.ini-dist : on
- php.ini-recommended : off
PHP 5_3:
- Default behaviour : on
- php.ini-development : off
- php.ini-production : off
php.ini descriptions : short_open_tag
In 5_2 our reason for discouraging it is:
; - short_open_tag = Off [Portability]
; Using short tags is discouraged when developing code meant for
redistribution
; since short tags may not be supported on the target server.
; Allow the <? tag. Otherwise, only <?php and <script> tags are
recognized.
; NOTE: Using short tags should be avoided when developing
applications or
; libraries that are meant for redistribution, or deployment on PHP
; servers which are not under your control, because short tags may not
; be supported on the target server. For portable, redistributable code,
; be sure not to use short tags.In 5_3 it's:
; This directive determines whether or not PHP will recognize code
between
; <? and ?> tags as PHP source which should be processed as such. It's
been
; recommended for several years that you not use the short tag "short
cut" and
; instead to use the full <?php and ?> tag combination. With the wide
spread use
; of XML and use of these tags by other languages, the server can
become easily
; confused and end up parsing the wrong code in the wrong context. But
because
; this short cut has been a feature for such a long time, it's
currently still
; supported for backwards compatibility, but we recommend you don't
use them.
This history strongly suggests PHP is hoping and subtly forcing the
world to stop using this directive, and although it's not deprecated
the wording and treatment makes it feel it could be any day now. This
situation must be clarified before 5_3 is released, and will likely
require our BDFL to do it.In related news, what came of this RFC? It still says "Under Discussion":
Regards,
Philip
Hello everyone.
I've been writing <?php echo get('something')?> for some time now at the
last project and it really sucks. I understand reason on depricating
short_open_tag and I agree. But I have a proposal witch can ease templating.
Remove short open tag, but leave <?=get('blah')?>. Bacicaly PHP parser
should look for <?php or <?=, single <? is not allowed. That way:
1). short_open_tag is gone for good as an option in .ini.
2). Making templates doesn't suck
3). Backwards compability with old templates is preserved (old templates
with <?= work fine).
4). <? in code is broken as you want it to be and makes coders fix it with
<?php
Everyone is happy, XML and others are safe.
Yes, it's really irritating to write <?php echo every time!
As Jani put it:
PLEASE, let the dead horse be!
- David
Hello everyone.
I've been writing <?php echo get('something')?> for some time now at
the
last project and it really sucks. I understand reason on depricating
short_open_tag and I agree. But I have a proposal witch can ease
templating.Remove short open tag, but leave <?=get('blah')?>. Bacicaly PHP parser
should look for <?php or <?=, single <? is not allowed. That way:
1). short_open_tag is gone for good as an option in .ini.
2). Making templates doesn't suck
3). Backwards compability with old templates is preserved (old
templates
with <?= work fine).
4). <? in code is broken as you want it to be and makes coders fix
it with
<?phpEveryone is happy, XML and others are safe.
Yes, it's really irritating to write <?php echo every time!
Hi!
PLEASE, let the dead horse be!
Apparently, this horse is not as dead as some would like it to be :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
PLEASE, let the dead horse be!
Apparently, this horse is not as dead as some would like it to be :)
The horse is not dead or if so then no proper burial service was
given. People are still waiting for the invitations and wanting to
hear the eulogy.
So, instead I'll make the following assumptions and engrave them into
this topics tombstone:
- short_open_tag is fully alive
- short_open_tag is PHP_INI_SYSTEM|PHP_INI_PERDIR
- all distributed php.ini files disable it (5.3+)
- the default will be enabled, forever, unless #5 is used
- --disable-short-tags will exist, forever
- no new alternative syntax will be implemented, ever
That's the situation people should understand and since this horse is
considered dead I will:
- update php.ini ini descriptions to reflect this
- update documentation to reflect this
- mark http://wiki.php.net/rfc/shortags as declined
- point to the declined rfc when people suggest these alternatives
All discussion is over unless a human knows the above synopsis is
false, because CVS has spoken. RIP.
Regards,
Philip
PLEASE, let the dead horse be!
Apparently, this horse is not as dead as some would like it to be :)
The horse is not dead or if so then no proper burial service was given.
People are still waiting for the invitations and wanting to hear the eulogy.So, instead I'll make the following assumptions and engrave them into this
topics tombstone:
- short_open_tag is fully alive
- short_open_tag is PHP_INI_SYSTEM|PHP_INI_PERDIR
- all distributed php.ini files disable it (5.3+)
- the default will be enabled, forever, unless #5 is used
- --disable-short-tags will exist, forever
- no new alternative syntax will be implemented, ever
That's the situation people should understand and since this horse is
considered dead I will:
- update php.ini ini descriptions to reflect this
- update documentation to reflect this
- mark http://wiki.php.net/rfc/shortags as declined
- point to the declined rfc when people suggest these alternatives
All discussion is over unless a human knows the above synopsis is false,
because CVS has spoken. RIP.
apparently somebody else brought up the shortag(specifically the <?= tag)
topic again, and I've noticed that you moved the rfc from declined to "In
discussion" recently (https://wiki.php.net/rfc/shortags?do=revisions), so I
would like to know that are these rules still hold, or did something
happened since this decision?
I couldn't find the suggested clarification in the docs either (maybe looked
at the wrong place)
Tyrael
Hi,
I'm that somebody Tyrael is talking about. FTR, I'm all for deprecating
short tags, but I do feel the echo shortcut is a separate issue. Perhaps if
<?php= was implemented a greater deal of people on both sides of the
discussion would be happier.
Best regards,
David
PLEASE, let the dead horse be!
Apparently, this horse is not as dead as some would like it to be :)
The horse is not dead or if so then no proper burial service was given.
People are still waiting for the invitations and wanting to hear the
eulogy.So, instead I'll make the following assumptions and engrave them into
this
topics tombstone:
- short_open_tag is fully alive
- short_open_tag is PHP_INI_SYSTEM|PHP_INI_PERDIR
- all distributed php.ini files disable it (5.3+)
- the default will be enabled, forever, unless #5 is used
- --disable-short-tags will exist, forever
- no new alternative syntax will be implemented, ever
That's the situation people should understand and since this horse is
considered dead I will:
- update php.ini ini descriptions to reflect this
- update documentation to reflect this
- mark http://wiki.php.net/rfc/shortags as declined
- point to the declined rfc when people suggest these alternatives
All discussion is over unless a human knows the above synopsis is false,
because CVS has spoken. RIP.apparently somebody else brought up the shortag(specifically the <?= tag)
topic again, and I've noticed that you moved the rfc from declined to "In
discussion" recently (https://wiki.php.net/rfc/shortags?do=revisions), so
I
would like to know that are these rules still hold, or did something
happened since this decision?
I couldn't find the suggested clarification in the docs either (maybe
looked
at the wrong place)Tyrael
apparently somebody else brought up the shortag(specifically the <?= tag) topic again, and I've noticed that you moved the rfc from declined to "In discussion" recently (https://wiki.php.net/rfc/shortags?do=revisions), so I would like to know that are these rules still hold, or did something happened since this decision?
I couldn't find the suggested clarification in the docs either (maybe looked at the wrong place)
The topic split into a few directions with "decoupling <?= from short_open_tag" being one of them. I moved it to "In discussion" because the decoupling idea gained traction although afair it wasn't discussed at length, but it's part of the 5.4 'to discuss' TODO[1].
Regards,
Philip
apparently somebody else brought up the shortag(specifically the <?= tag) topic again, and I've noticed that you moved the rfc from declined to "In discussion" recently (https://wiki.php.net/rfc/shortags?do=revisions), so I would like to know that are these rules still hold, or did something happened since this decision?
I couldn't find the suggested clarification in the docs either (maybe looked at the wrong place)The topic split into a few directions with "decoupling <?= from short_open_tag" being one of them. I moved it to "In discussion" because the decoupling idea gained traction although afair it wasn't discussed at length, but it's part of the 5.4 'to discuss' TODO[1].
Regards,
Philip
As far as I remember there weren't any serious objections to decoupling
<?= and leaving it always enabled. It doesn't interfere with other PI
tags in a file, and nobody else is going to come along and use it on us.
-Rasmus
Hi!
As far as I remember there weren't any serious objections to decoupling
<?= and leaving it always enabled. It doesn't interfere with other PI
tags in a file, and nobody else is going to come along and use it on us.
That's what I think too, but since there was no agreement fixed on that,
I put it into discussion part.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
So what would be there to discuss or agree on?, now that the topic is at
hand.
Regards,
David
On Wed, May 18, 2011 at 9:05 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
As far as I remember there weren't any serious objections to decoupling
<?= and leaving it always enabled. It doesn't interfere with other PI
tags in a file, and nobody else is going to come along and use it on us.That's what I think too, but since there was no agreement fixed on that, I
put it into discussion part.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hello.
As a userland developer i'm all for it. Remove short_tags and decouple
<?= from them to be in PHP core always on.
2011/5/19 dukeofgaming dukeofgaming@gmail.com:
So what would be there to discuss or agree on?, now that the topic is at
hand.Regards,
David
On Wed, May 18, 2011 at 9:05 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
As far as I remember there weren't any serious objections to decoupling
<?= and leaving it always enabled. It doesn't interfere with other PI
tags in a file, and nobody else is going to come along and use it on us.That's what I think too, but since there was no agreement fixed on that, I
put it into discussion part.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Thu, May 19, 2011 at 8:53 AM, Arvids Godjuks arvids.godjuks@gmail.comwrote:
Hello.
As a userland developer i'm all for it. Remove short_tags and decouple
<?= from them to be in PHP core always on.
I think that it's a little bit hasty.
I would propose that the short open echo should be always enabled
independently from the short_open_tag, and this should be documented and
done with it.
Tyrael
It's essentially the same what I said - move it out of stort_tags and
make it "On" permanently.
As I remember the decision to remove short_tags was made together with
register_globals, magic_quotes and other legacy stuff. I can be that I
remember wrongly, but really do people really use <% ?
2011/5/19 Ferenc Kovacs info@tyrael.hu:
On Thu, May 19, 2011 at 8:53 AM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:Hello.
As a userland developer i'm all for it. Remove short_tags and decouple
<?= from them to be in PHP core always on.I think that it's a little bit hasty.
I would propose that the short open echo should be always enabled
independently from the short_open_tag, and this should be documented and
done with it.
Tyrael
Some time ago I floated this idea without any traction. I wanted to make an
RFC but never got any help in setting up an account to submit it. Here it
is again:
Tag style can be set from the ini file, htaccess/httpdconfig or changed at
runtime. If changed at runtime it only affects files that haven't been
included yet. Tag Style can also be passed as the second argument to the
include, include_once, require, and require_once statements. Those
statements fall back to the current setting if a second argument isn't
passed. The tag style is a bitfield as follows:
Bit
0 -- Standard tags toggle
1 -- Short tags toggle
2 -- ASP tags toggle
3 -- Script tags toggle
4 -- Short echo toggle.
For backwards compat ship with bits 0 and 3 set on. The existing short tags
mode is bits 1 and 4 on. If all the bits are turned off then we have the
PHP_TAGS_NONE setting. In that mode the engine assumes the whole file is
going to be PHP code since there will be no tags at all (helpful for class
libraries that don't create output in the MVC architecture).
If the php.ini file has either of the legacy tag settings turned on, and
tag_style wasn't explicitly set, then php will set tag style to the values
it must have to mimic the intent of the setting. If tag_style is explicitly
set then it wins out - but a deprecated notice gets thrown to alert the user
that they have both tag_style set and short_open_tags and/or asp_tags set
on.
If an htaccess or httpd.conf directive explicitly calls for short_tags or
asp_tags after tag_style was explicitly set a warning of some sort is thrown
informing the user that they must switch that declaration to one compatible
with the php.ini file.
The upshot of this is to allow distributions that want to use short tags to
be able to use them without worrying about local server settings. Also,
distributions can be made to contain files without any tags at all.
Teaching IDE's that it is possible for a PHP file to have no <?php ?> tags
could be tricky though.
On Thu, May 19, 2011 at 3:23 AM, Arvids Godjuks arvids.godjuks@gmail.comwrote:
It's essentially the same what I said - move it out of stort_tags and
make it "On" permanently.As I remember the decision to remove short_tags was made together with
register_globals, magic_quotes and other legacy stuff. I can be that I
remember wrongly, but really do people really use <% ?2011/5/19 Ferenc Kovacs info@tyrael.hu:
On Thu, May 19, 2011 at 8:53 AM, Arvids Godjuks <
arvids.godjuks@gmail.com>
wrote:Hello.
As a userland developer i'm all for it. Remove short_tags and decouple
<?= from them to be in PHP core always on.I think that it's a little bit hasty.
I would propose that the short open echo should be always enabled
independently from the short_open_tag, and this should be documented and
done with it.
Tyrael
I like the idea of having an option for no tags needed, since its a .php
file (or what ever you have set as your interpd name) that gets sent to the
interpreter anyway, it shouldnt really need opening tag,
the only thing of this that i dont like is the runtime side of it, imo that
shouldnt be an option
On Thu, May 19, 2011 at 3:39 PM, Michael Morris dmgx.michael@gmail.comwrote:
Some time ago I floated this idea without any traction. I wanted to make an
RFC but never got any help in setting up an account to submit it. Here it
is again:Tag style can be set from the ini file, htaccess/httpdconfig or changed at
runtime. If changed at runtime it only affects files that haven't been
included yet. Tag Style can also be passed as the second argument to the
include, include_once, require, and require_once statements. Those
statements fall back to the current setting if a second argument isn't
passed. The tag style is a bitfield as follows:Bit
0 -- Standard tags toggle
1 -- Short tags toggle
2 -- ASP tags toggle
3 -- Script tags toggle
4 -- Short echo toggle.For backwards compat ship with bits 0 and 3 set on. The existing short tags
mode is bits 1 and 4 on. If all the bits are turned off then we have the
PHP_TAGS_NONE setting. In that mode the engine assumes the whole file is
going to be PHP code since there will be no tags at all (helpful for class
libraries that don't create output in the MVC architecture).If the php.ini file has either of the legacy tag settings turned on, and
tag_style wasn't explicitly set, then php will set tag style to the values
it must have to mimic the intent of the setting. If tag_style is explicitly
set then it wins out - but a deprecated notice gets thrown to alert the
user
that they have both tag_style set and short_open_tags and/or asp_tags set
on.If an htaccess or httpd.conf directive explicitly calls for short_tags or
asp_tags after tag_style was explicitly set a warning of some sort is
thrown
informing the user that they must switch that declaration to one compatible
with the php.ini file.The upshot of this is to allow distributions that want to use short tags to
be able to use them without worrying about local server settings. Also,
distributions can be made to contain files without any tags at all.
Teaching IDE's that it is possible for a PHP file to have no <?php ?> tags
could be tricky though.On Thu, May 19, 2011 at 3:23 AM, Arvids Godjuks <arvids.godjuks@gmail.com
wrote:
It's essentially the same what I said - move it out of stort_tags and
make it "On" permanently.As I remember the decision to remove short_tags was made together with
register_globals, magic_quotes and other legacy stuff. I can be that I
remember wrongly, but really do people really use <% ?2011/5/19 Ferenc Kovacs info@tyrael.hu:
On Thu, May 19, 2011 at 8:53 AM, Arvids Godjuks <
arvids.godjuks@gmail.com>
wrote:Hello.
As a userland developer i'm all for it. Remove short_tags and decouple
<?= from them to be in PHP core always on.I think that it's a little bit hasty.
I would propose that the short open echo should be always enabled
independently from the short_open_tag, and this should be documented
and
done with it.
Tyrael
I don't think this problems calls for a more flexible solution. On the
other hand I think the flexibility is the problem. Today if I want
to write compatible php code I can neither use:
<?foreach($rows as $row):?> ...
or
<?xml ...
in my template files. Bummer! :)
I would much prefer that one and only one tag setting was chosen as
the official one and that a very slow deprecation path was taken so we
in the end could remove the other ones. One less thing to think about.
I like the idea of having an option for no tags needed, since its a .php
file (or what ever you have set as your interpd name) that gets sent to the
interpreter anyway, it shouldnt really need opening tag,the only thing of this that i dont like is the runtime side of it, imo that
shouldnt be an optionOn Thu, May 19, 2011 at 3:39 PM, Michael Morris dmgx.michael@gmail.comwrote:
Some time ago I floated this idea without any traction. I wanted to make an
RFC but never got any help in setting up an account to submit it. Here it
is again:Tag style can be set from the ini file, htaccess/httpdconfig or changed at
runtime. If changed at runtime it only affects files that haven't been
included yet. Tag Style can also be passed as the second argument to the
include, include_once, require, and require_once statements. Those
statements fall back to the current setting if a second argument isn't
passed. The tag style is a bitfield as follows:Bit
0 -- Standard tags toggle
1 -- Short tags toggle
2 -- ASP tags toggle
3 -- Script tags toggle
4 -- Short echo toggle.For backwards compat ship with bits 0 and 3 set on. The existing short tags
mode is bits 1 and 4 on. If all the bits are turned off then we have the
PHP_TAGS_NONE setting. In that mode the engine assumes the whole file is
going to be PHP code since there will be no tags at all (helpful for class
libraries that don't create output in the MVC architecture).If the php.ini file has either of the legacy tag settings turned on, and
tag_style wasn't explicitly set, then php will set tag style to the values
it must have to mimic the intent of the setting. If tag_style is explicitly
set then it wins out - but a deprecated notice gets thrown to alert the
user
that they have both tag_style set and short_open_tags and/or asp_tags set
on.If an htaccess or httpd.conf directive explicitly calls for short_tags or
asp_tags after tag_style was explicitly set a warning of some sort is
thrown
informing the user that they must switch that declaration to one compatible
with the php.ini file.The upshot of this is to allow distributions that want to use short tags to
be able to use them without worrying about local server settings. Also,
distributions can be made to contain files without any tags at all.
Teaching IDE's that it is possible for a PHP file to have no <?php ?> tags
could be tricky though.On Thu, May 19, 2011 at 3:23 AM, Arvids Godjuks <arvids.godjuks@gmail.com
wrote:
It's essentially the same what I said - move it out of stort_tags and
make it "On" permanently.As I remember the decision to remove short_tags was made together with
register_globals, magic_quotes and other legacy stuff. I can be that I
remember wrongly, but really do people really use <% ?2011/5/19 Ferenc Kovacs info@tyrael.hu:
On Thu, May 19, 2011 at 8:53 AM, Arvids Godjuks <
arvids.godjuks@gmail.com>
wrote:Hello.
As a userland developer i'm all for it. Remove short_tags and decouple
<?= from them to be in PHP core always on.I think that it's a little bit hasty.
I would propose that the short open echo should be always enabled
independently from the short_open_tag, and this should be documented
and
done with it.
Tyrael
It's essentially the same what I said - move it out of stort_tags and
make it "On" permanently.As I remember the decision to remove short_tags was made together with
register_globals, magic_quotes and other legacy stuff. I can be that I
remember wrongly, but really do people really use<% ?
Would be really nice if '<?' with a whitespace as the next byte was
also detected (i.e. '<? ', '<?\n', etc). (Single-quotes have been added
to aid readability.)
The '<? ' short tag is syntactic sugary convenience that is widely
used: Internal corporate servers, personal machines, and millions upon
millions of websites. The results and financial costs of cleaning up
the upgrade fallout of removing the '<? ' short tag are incalculable.
Comparing short tags to magic_quotes/register_globals is apples to
oranges. The two are so vastly different and not in the same class.
The latter is a failed security measure. The former is a syntactic
sugary convenience. Every PHP userland developer I know understands the
risks associated with magic_quotes and register_globals but, at the same
time, they use the '<? ' short tag extensively wherever possible.
Or, perhaps more simply put: If you remove the "syntactic sugary
convenience" of the '<? ' short tag, you'll have an army of developers
dropping by shortly after the release of PHP 6 and they will be
incredibly unhappy. But you just go ahead and remove the '<? ' short
tag for PHP 6. You'll be adding it back into PHP 6.0.1.
The ONLY reason anyone types '<?php ' in the first place is because '<?
' isn't guaranteed to work everywhere. And that rule really only
applies to open source software and certain web hosts, which is a very
small segment of the total PHP market share. It would probably be fine
if you removed the option itself but merged '<? ' detection into the
core. I don't know anyone who uses anything but '<? ', so it won't
likely be a huge loss for anyone if '<% ' support is dropped (but I
could be wrong about that).
The important part of this discussion is making sure convenient
functionality doesn't just vanish for stupid reasons. I recognize there
will be breakage regardless because it is a new major version, but
looking ahead one extra byte isn't going to kill you.
--
Thomas Hruska
CubicleSoft President
Barebones CMS is a high-performance, open source content management
system for web developers operating in a team environment.
An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
Something I would add to this - I personally do use short tags in an open
source project because mod_rewrite functionality, implemented either at the
.htaccess level or at the httpd.config level. In either event, if you can
use mod_rewrite, setting the php flag for short tags is trivial so I know it
will be available. It's simply not possible (that I know of) to config a
server such that mod_rewrite is available and php_flags short_open_tags will
not be.
On Thu, May 19, 2011 at 11:35 AM, Thomas Hruska thruska@cubiclesoft.comwrote:
It's essentially the same what I said - move it out of stort_tags and
make it "On" permanently.As I remember the decision to remove short_tags was made together with
register_globals, magic_quotes and other legacy stuff. I can be that I
remember wrongly, but really do people really use<% ?Would be really nice if '<?' with a whitespace as the next byte was
also detected (i.e. '<? ', '<?\n', etc). (Single-quotes have been added to
aid readability.)The '<? ' short tag is syntactic sugary convenience that is widely
used: Internal corporate servers, personal machines, and millions upon
millions of websites. The results and financial costs of cleaning up the
upgrade fallout of removing the '<? ' short tag are incalculable.Comparing short tags to magic_quotes/register_globals is apples to oranges.
The two are so vastly different and not in the same class. The latter is a
failed security measure. The former is a syntactic sugary convenience.
Every PHP userland developer I know understands the risks associated with
magic_quotes and register_globals but, at the same time, they use the '<? '
short tag extensively wherever possible.Or, perhaps more simply put: If you remove the "syntactic sugary
convenience" of the '<? ' short tag, you'll have an army of developers
dropping by shortly after the release of PHP 6 and they will be incredibly
unhappy. But you just go ahead and remove the '<? ' short tag for PHP 6.
You'll be adding it back into PHP 6.0.1.The ONLY reason anyone types '<?php ' in the first place is because '<? '
isn't guaranteed to work everywhere. And that rule really only applies to
open source software and certain web hosts, which is a very small segment of
the total PHP market share. It would probably be fine if you removed the
option itself but merged '<? ' detection into the core. I don't know
anyone who uses anything but '<? ', so it won't likely be a huge loss for
anyone if '<% ' support is dropped (but I could be wrong about that).The important part of this discussion is making sure convenient
functionality doesn't just vanish for stupid reasons. I recognize there
will be breakage regardless because it is a new major version, but looking
ahead one extra byte isn't going to kill you.--
Thomas Hruska
CubicleSoft PresidentBarebones CMS is a high-performance, open source content management system
for web developers operating in a team environment.An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
@Michael
Those are interesting ideas, I think you can register by yourself on the
wiki, so you can add the RFC. OTOH, and again, I must say I really think the
echo shortcut should be regarded as a separate issue, and now that there was
some consensus we shouldn't deviate from the topic.
In the end I think it is going to be as bad to have short open tags turned
off by default. Hosting services still meddle with the php.ini and some even
let you make your own customizations to it (or at least to a subset of it).
But again, can we first agree on the echo shortcut feature to be decoupled
from short tags?. No agreements === no progress.
BTW, what is your open source project?
@Thomas
I agree on dropping <% for good, I personally don't know any project that
uses it and don't think there is currently any point to them anymore.
Also, I do use '<? ' instead of '<?' (originall I thought it might throw an
error, then it became habit), although I try not tu use <? as much as <?=.
Having the space as a requirement (i.e. "<?for(..." would throw an error)
would fix the XML situation, is this what you are saying?.
@all
Can we decide on decoupling <?= before going back to the general short tag
matter?
On Thu, May 19, 2011 at 10:35 AM, Thomas Hruska thruska@cubiclesoft.comwrote:
It's essentially the same what I said - move it out of stort_tags and
make it "On" permanently.As I remember the decision to remove short_tags was made together with
register_globals, magic_quotes and other legacy stuff. I can be that I
remember wrongly, but really do people really use<% ?Would be really nice if '<?' with a whitespace as the next byte was
also detected (i.e. '<? ', '<?\n', etc). (Single-quotes have been added to
aid readability.)The '<? ' short tag is syntactic sugary convenience that is widely
used: Internal corporate servers, personal machines, and millions upon
millions of websites. The results and financial costs of cleaning up the
upgrade fallout of removing the '<? ' short tag are incalculable.Comparing short tags to magic_quotes/register_globals is apples to oranges.
The two are so vastly different and not in the same class. The latter is a
failed security measure. The former is a syntactic sugary convenience.
Every PHP userland developer I know understands the risks associated with
magic_quotes and register_globals but, at the same time, they use the '<? '
short tag extensively wherever possible.Or, perhaps more simply put: If you remove the "syntactic sugary
convenience" of the '<? ' short tag, you'll have an army of developers
dropping by shortly after the release of PHP 6 and they will be incredibly
unhappy. But you just go ahead and remove the '<? ' short tag for PHP 6.
You'll be adding it back into PHP 6.0.1.The ONLY reason anyone types '<?php ' in the first place is because '<? '
isn't guaranteed to work everywhere. And that rule really only applies to
open source software and certain web hosts, which is a very small segment of
the total PHP market share. It would probably be fine if you removed the
option itself but merged '<? ' detection into the core. I don't know
anyone who uses anything but '<? ', so it won't likely be a huge loss for
anyone if '<% ' support is dropped (but I could be wrong about that).The important part of this discussion is making sure convenient
functionality doesn't just vanish for stupid reasons. I recognize there
will be breakage regardless because it is a new major version, but looking
ahead one extra byte isn't going to kill you.--
Thomas Hruska
CubicleSoft PresidentBarebones CMS is a high-performance, open source content management system
for web developers operating in a team environment.An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
@all
Can we decide on decoupling <?= before going back to the general short tag
matter?
It feels like decoupling <?= from short_open_tag will happen. And I've not seen objections or reasons for not doing it, so think we can safely assume that it's been decided.
Regards,
Philip
@all
Can we decide on decoupling <?= before going back to the general short
tag
matter?It feels like decoupling <?= from short_open_tag will happen. And I've not
seen objections or reasons for not doing it, so think we can safely assume
that it's been decided.
Awesome
On Thu, May 19, 2011 at 7:52 PM, dukeofgaming dukeofgaming@gmail.comwrote:
On Thu, May 19, 2011 at 11:17 AM, Philip Olson philip@roshambo.org
wrote:@all
Can we decide on decoupling <?= before going back to the general short
tag
matter?It feels like decoupling <?= from short_open_tag will happen. And I've
not
seen objections or reasons for not doing it, so think we can safely
assume
that it's been decided.Awesome
http://svn.php.net/viewvc?view=revision&revision=311260
Rasmus committed it for 5.4 \o/
Tyrael
@Thomas
I agree on dropping<% for good, I personally don't know any project that
uses it and don't think there is currently any point to them anymore.Also, I do use '<? ' instead of '<?' (originall I thought it might throw an
error, then it became habit), although I try not tu use<? as much as<?=.
Having the space as a requirement (i.e. "<?for(..." would throw an error)
would fix the XML situation, is this what you are saying?.
Yes.
--
Thomas Hruska
CubicleSoft President
Barebones CMS is a high-performance, open source content management
system for web developers operating in a team environment.
An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
On Tue, Apr 14, 2009 at 03:11:10PM GMT, Arvids Godjuks [arvids.godjuks@gmail.com] said the following:
Yes, it's really irritating to write <?php echo every time!
Until you get used to it. I started with PHP back in 98 and remember
a bit of resistance in learning the <?php thing, but I knew it was for
the best and now I'm not regretting it. For me, its just normal now.
--
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/
It was not my intention to initiate a massive debate regarding the use
of short_open_tag.
I posted for two reasons:
- To ask if short_open_tag has been deprecated in PHP 6.
- To suggest asp_tags as the recommended option for templating in PHP
(to keep both crowds* happy).
- The crowd for the use of short_open_tag (I don't believe that they
are in favour of this tag because of the particular characters used, but
rather because of its shortness), and the crowd against its use
(believing that, since PHP's primary use is for embedding code within
HTML documents, it should respect the use of other processing instructions).
Glen.
Jeremy wrote:
Glen wrote:
It's short, and it doesn't conflict with XML.
I have to say, I don't understand all the hate on short_open_tag. So
what if it "conflicts" with XML? PHP is not XML. If you use an XML
construct in your PHP, escape it. PHP can generate a lot of other
languages, too -- should every construct from these languages be
forbidden in PHP as well?Jeremy