Hi!
Forwarding this mail again since apparently many people missed it
previously. Please discuss.
-------- Original Message --------
Subject: short_open_tag
Date: Fri, 07 Mar 2008 12:45:59 -0800
From: Stanislav Malyshev stas@zend.com
Hi!
I wonder - is there a reason why short_open_tag config value is per-dir
and not PHP_INI_ALL? After all, as I understand, it is private for each
compilation. So suppose you preferred it generally off (you do XML,
etc.) but you have some files in your app where you want it on - would
there be any problem anywhere if it were INI_ALL?
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
thanks for rewriting this.
Friday, March 21, 2008, 6:57:40 PM, you wrote:
Hi!
Forwarding this mail again since apparently many people missed it
previously. Please discuss.
-------- Original Message --------
Subject: short_open_tag
Date: Fri, 07 Mar 2008 12:45:59 -0800
From: Stanislav Malyshev stas@zend.com
Hi!
I wonder - is there a reason why short_open_tag config value is per-dir
and not PHP_INI_ALL? After all, as I understand, it is private for each
compilation. So suppose you preferred it generally off (you do XML,
etc.) but you have some files in your app where you want it on - would
there be any problem anywhere if it were INI_ALL?
For me the largest issue is infact late enabling of short tags at run time.
The issue tracks down to the issue where peole might use code that enables
short open tags but forgets to disable that. Now why might I rely on short
open tags being disabled is another question of course. Years ago when we
last discussed whether we should discourage them the conclusion was that
not many people rely on them being off. Today many people have php code
interact with XML code which sees short open tags as invalid PIs. Thus we
should try to discourage maybe even finally deprecate short open tags. This
would also be in line with the rest of PHP where we block and discourage
short syntactical sugar when all it does is saving keystrokes. With short
open tags the argument usually simply is that '<?=$bla?>' is shorther than
writing '<?php echo $bla:?>'. But then again the former is much harder to
spot in manual written code. And for generated code it doesn't matter at
all. That said I am against short open tags. And given my first part. I do
not want to deal with code that does 'php_ini_set("short_open_tags", 0);'
after every single include or require statement.
Best regards,
Marcus
Hi!
For me the largest issue is infact late enabling of short tags at run time.
The issue tracks down to the issue where peole might use code that enables
short open tags but forgets to disable that. Now why might I rely on short
I think this case is very unlikely. The use case for this feature is
template system, written in long-tags style, but using short-tags
notation for PHP templates. To compare:
My name is <?= $name ?> and I am <?= $age ?> years old.
My name is <?php echo $name; ?> and I am <?php echo $age; ?> years old.
I think there's little doubt people - especially non-programmer people
like designers - would have much less trouble understanding and writing
first notation than second notation. If you compare larger, more complex
templates, the difference in readability is even bigger. And having code
easy to work with is one of the reasons people do PHP.
Now, in a template system, it is really hard to imagine that template
system creator would be so sloppy as to intend to write code like:
setShortTags();
include $user_template;
resetShortTags();
and somehow "forget" to write the last function. That would require
extreme absent-mindedness on developer's part and you definitely should
steer clear of template systems written by such people. However, for
real template systems I know - they are written by very smart people,
and actually these people support this capability, as it allows them to
use nice syntax in templates without requiring any system configuration
(which may be unavailable or incompatible with other code).
open tags being disabled is another question of course. Years ago when we
This is very important question, since the only known case of why it
might be important is when you use XML as template by including it
directly through PHP parser. I don't think I would be mistaken if I say
this is extremely rare use case. Actually, I'm not sure there's even one
of common applications - like known CMSes, frameworks, blog platforms,
e-commerce platforms, etc. - that can not work with short tags. Can you
name which ones can't?
Again, I consider the concept of "accidentally enabling" sort tags very
improbable, but even if it somehow happened - IMO it would not be a
problem except in some very rare use cases.
last discussed whether we should discourage them the conclusion was that
not many people rely on them being off. Today many people have php code
And if you look at the discussion, there were opinions - including
Zeev's - that there's nothing wrong with shorts tags in general, only in
some rare use cases.
short syntactical sugar when all it does is saving keystrokes. With short
open tags the argument usually simply is that '<?=$bla?>' is shorther than
writing '<?php echo $bla:?>'. But then again the former is much harder to
spot in manual written code. And for generated code it doesn't matter at
I have hard time figuring out a use case when you need to "spot" this in
your code - and, indeed, have one in your code at all, unless it is a
template. In a template, <?= is much better and with any decent editor,
very easy to spot.
all. That said I am against short open tags. And given my first part. I do
not want to deal with code that does 'php_ini_set("short_open_tags", 0);'
after every single include or require statement.
You do not need to deal with this code, and there's absolutely no reason
to do it. Only case when you may need to do it if you include hostile
code - i.e. code that can intentionally try and screw up your
environment. In this case, this code might do much worse things than
screw with your short tags setting, which in 99.99% of cases wouldn't do
anything - that code might drop your include path, unset your variables,
close your files and DB connections, reset your memory limit and
execution time to very low values, rewire charsets on input and output,
install any kinds of stream filters, turn on magic quotes, and do a ton
of other very bad things like messing with your file system and what
not. Still all those variables and settings are user-accessible. And you
are not worried about restoring your include path or resetting your
magic quotes or memory limits after each include.
And on top of that - if you are still concerned, you always could do
php_admin_value which IIRC blocks setting values by user.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev kirjoitti:
I think this case is very unlikely. The use case for this feature is
template system, written in long-tags style, but using short-tags
notation for PHP templates. To compare:My name is <?= $name ?> and I am <?= $age ?> years old.
My name is <?php echo $name; ?> and I am <?php echo $age; ?> years old.
I'd rather see <?php= than having this whole "short_open_tag" thing at all.
I'd even use it myself. But I will not EVER enable the damn short tags again.
And won't allow anyone else doing it either. And speaking of hostile code: ALL
code is hostile unless you wrote it yourself. Have you ever heard of a group of
developers working on same code base? Like, say, in a company that develops
apps? If you allow changing this thing in runtime, it's adding another potential
pitfall to check for when all hell breaks loose and something starts misbehaving
and you have no idea why. Time spend on finding the cause would be better spend
coding new stuff.
And as you yourself instructed to check for "short_open_tag" in the archive
search: Count how many hits it gives which talk about problems with it.
(and no, none of those people ask about "why can't I enable it in runtime..")
--Jani
I'd rather see <?php= than having this whole "short_open_tag" thing at all.
Does <?php= work? I though echo shortcut works only with short tags.
<?php= is not much worse than <?= so it'd be OK with me. Downside would
be template systems couldn't use it until 5.3 is widely deployed - which
means no template system can use it as standard for about 2-3 years at
least. Unless we put <?php= in 5.2, which would make me a happy camper,
but might be a trouble for others.
I'd even use it myself. But I will not EVER enable the damn short tags
again. And won't allow anyone else doing it either. And speaking of
What's wrong with short tags, can anybody explain me?
hostile code: ALL code is hostile unless you wrote it yourself. Have you
Not true. You probably use a ton of libraries, never verifying they
don['t screw up your include path, memory limits, etc.? Why short tags
are so different?
And as you yourself instructed to check for "short_open_tag" in the
archive search: Count how many hits it gives which talk about problems
with it.
Can you show which exactly search query you used, so we'd be sure we are
talking about the same thing?
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Friday, March 21, 2008, 8:37:18 PM, you wrote:
I'd rather see <?php= than having this whole "short_open_tag" thing at all.
Does <?php= work? I though echo shortcut works only with short tags.
<?php= is not much worse than <?= so it'd be OK with me. Downside would
be template systems couldn't use it until 5.3 is widely deployed - which
means no template system can use it as standard for about 2-3 years at
least. Unless we put <?php= in 5.2, which would make me a happy camper,
but might be a trouble for others.
The problem with '<?php=' is that it still doesn't work with XML tools.
However the '<?echo' I mentioned would work. We could also go for something
like '<?phpecho'. I for one would really appreciate it. And I would not
mind adding that to 5.2 if that makes you happy. But I care to less for it
to be available tomorrow.
Best regards,
Marcus
However the '<?echo' I mentioned would work. We could also go for something
like '<?phpecho'. I for one would really appreciate it. And I would not
<?phpecho is too long. Really, saving one space here isn't worth a
trouble. If we had something short and nice like <?= that'd be good and
would make PHP templates look clean, but doing <?phpecho instead of
<?php echo - how does it make any real difference?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Friday, March 21, 2008, 9:08:02 PM, you wrote:
However the '<?echo' I mentioned would work. We could also go for something
like '<?phpecho'. I for one would really appreciate it. And I would not
<?phpecho is too long. Really, saving one space here isn't worth a
trouble. If we had something short and nice like <?= that'd be good and
would make PHP templates look clean, but doing <?phpecho instead of
<?php echo - how does it make any real difference?
The thing is that <?php echo would require a ; while <?phpecho wouldn't.
And if you ronly argument is saving a few keystrokes then we should really
get rid of short open tags completely. And definitively not making their
use easier.
Best regards,
Marcus
The thing is that <?php echo would require a ; while <?phpecho wouldn't.
And if you ronly argument is saving a few keystrokes then we should really
get rid of short open tags completely. And definitively not making their
use easier.
It is easier to use templates with <?= ?> then with full PHP syntax,
they look cleaner. Just look how many other templates use "tag" syntax -
either {SOMETHING} or <%= SOMETHING %> or some like that. Do you that's
because they are too stupid or too lazy - or because they listen to the
users? ASP, JSP and Ruby all have <%=, does it teach us anything about
people liking short tags?
Look how many examples you short syntax - why is that? Because it looks
better and easy to read. And the only objection to that is - it's not
valid XML. OK, it is not valid XML - why should it be? Why should PHP
programmer work harder and PHP code look worse than Ruby, JSP or ASP -
just because of arbitrary requirement of XML compliance?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi,
Hello Stanislav,
Friday, March 21, 2008, 9:08:02 PM, you wrote:
However the '<?echo' I mentioned would work. We could also go for something
like '<?phpecho'. I for one would really appreciate it. And I would not<?phpecho is too long. Really, saving one space here isn't worth a
trouble. If we had something short and nice like <?= that'd be good and
would make PHP templates look clean, but doing <?phpecho instead of
<?php echo - how does it make any real difference?The thing is that <?php echo would require a ; while <?phpecho wouldn't.
And if you ronly argument is saving a few keystrokes then we should really
get rid of short open tags completely. And definitively not making their
use easier.
You don't need a ; in front of the ?> therefore <?php echo $foo ?>
works, so the only thing "<?phpecho" saves in fact is one character.
The point about <?= is that it is very short. <?=$foo?> can work quite
nice in simple templating stuff ("PHP is a templating language")
I also think that there aren't many people who preprocess "PHP Hypertext
preprocessor" files with XML-Tools, and if they do they won't use <?.
The XML issue I see there is the conflict with XML-PIs like <?xml which
starts PHP's processing. See [1] as a starting point for that. Already
the second result there [2] shows a real life example where the patch
Stas committed might be useful. In a file called "header.php" - which
certainly isn't the main script - the developer made sure that his
script works with both settings, so on the one hand he has to print the
"<?xml" PI using PHP, so there's no problem with short open tags, but
for outputting variables on the other hand he uses the long tags since
one can't rely on the fact that short tags are working. Using the patch
Stas proposed (and committed) this might be made nicer. I could look for
my own code where I had the same problem inside complexer stuff, but I
guess that random example, which took me <5 minutes to find shows the
possible benefit.
So as long as we have open tags I'd like Stas' patch. The only downside
I see are confused users ("Why doesn't that work for the script I have
that in") but well, we have such users for all stuff we do ;-)
Now we have the big issue: Do we want to have short open tags forever?
Well, without tooo much thinking my idea would be to drop "<?" but keep
"<?=", "<?=" shouldn't conflict with <?xml tags in the same file, but
make it simple to do templating using PHP, on the other hand when not
echo'ing stuff you already have to write more soo the four additional
characters ("php ") don't matter that much - especially every decent
editor/ide should be able to give you a completion on that, if you want.
But such a change in the language should go with other breaks to 6.0 or
so.
johannes
[1] <http://google.com/codesearch?hl=en&lr=&q=lang%3Aphp+%3C%5C%3Fphp
+echo+%5B%22%27%5D%3C%5C%3Fxml&btnG=Search>
[2] <http://google.com/codesearch?hl=en&q=+lang:php+%3C%5C%3Fphp+echo+%
5B%22%27%5D%3C%5C%3Fxml%22
+show:r_a97k72yKQ:0ofXUwlCDds:HkOUVl3hPgM&sa=N&cd=2&ct=rc&cs_p=http://managedtasks.com/wpthemes/gespaa_v2.zip&cs_f=gespaa_v2/header.php#first
Johannes Schlüter schrieb:
<ul> <? foreach ($items as $item): ?> <li><?=$item?></li> <? endforeach ?> </ul>Now we have the big issue: Do we want to have short open tags forever?
Well, without tooo much thinking my idea would be to drop "<?" but keep
"<?=", "<?=" shouldn't conflict with <?xml tags in the same file, but
make it simple to do templating using PHP, on the other hand when not
echo'ing stuff you already have to write more soo the four additional
characters ("php ") don't matter that much - especially every decent
editor/ide should be able to give you a completion on that, if you want.
you can have short stuff without outputting stuff too.
Regards,
Stefan
P.S.
This patch will be the most useful addition to PHP that has been added
for a long time, provided the purists and
i-don't-know-how-to-write-testcases-the-right-way folks don't succeed in
shooting it down.
Stefan Walk wrote:
Johannes Schlüter schrieb:
<ul> <? foreach ($items as $item): ?> <li><?=$item?></li> <? endforeach ?> </ul>Now we have the big issue: Do we want to have short open tags forever?
Well, without tooo much thinking my idea would be to drop "<?" but keep
"<?=", "<?=" shouldn't conflict with <?xml tags in the same file, but
make it simple to do templating using PHP, on the other hand when not
echo'ing stuff you already have to write more soo the four additional
characters ("php ") don't matter that much - especially every decent
editor/ide should be able to give you a completion on that, if you want.you can have short stuff without outputting stuff too.
I see many good reasons to disable short open tags. However, there is a
compromise that is better from all vantage points:
<?p is a valid PI and would prevent <?xml from being parsed as PHP.
Also legal is <?: as PI's can start with or contain : or _. Honestly
though, this is not so important to me, my primary concern is the
conflict with <?xml. I mention it out of deference for those who
actually do care about writing scripts that are xml-compliant for some
strange reason :). Also possible and relatively simple to implement
would be to allow an = at the start of an expression to alias to T_ECHO,
so that <?p =$item ?> would work like <?=$item?>. This is, however,
very perl-ish, so I mention it only as a possible way to preserve that
aspect of short tags for template usage. God forbid we start seeing
regular scripts using "=" to mean "echo" :).
As a note, I use exclusively <?php in my templates and also use <?xml to
generate xhtml, so I am very much against per-script enabling of short
tag <? for the annoyance it would introduce of forcing an ini_set() at
the top of each template and the bottom as well to be a good citizen and
restore the old value.
Greg
Hello Gregory,
Sunday, March 23, 2008, 12:13:20 AM, you wrote:
Stefan Walk wrote:
Johannes Schlüter schrieb:
<ul> <? foreach ($items as $item): ?> <li><?=$item?></li> <? endforeach ?> </ul>Now we have the big issue: Do we want to have short open tags forever?
Well, without tooo much thinking my idea would be to drop "<?" but keep
"<?=", "<?=" shouldn't conflict with <?xml tags in the same file, but
make it simple to do templating using PHP, on the other hand when not
echo'ing stuff you already have to write more soo the four additional
characters ("php ") don't matter that much - especially every decent
editor/ide should be able to give you a completion on that, if you want.you can have short stuff without outputting stuff too.
I see many good reasons to disable short open tags. However, there is a
compromise that is better from all vantage points:
<ul> <?p foreach ($items as $item): ?> <li><?=$item ?></li> <?p endforeach ?> </ul>
<?p is a valid PI and would prevent <?xml from being parsed as PHP.
Also legal is <?: as PI's can start with or contain : or _. Honestly
though, this is not so important to me, my primary concern is the
conflict with <?xml. I mention it out of deference for those who
actually do care about writing scripts that are xml-compliant for some
strange reason :). Also possible and relatively simple to implement
would be to allow an = at the start of an expression to alias to T_ECHO,
so that <?p =$item ?> would work like <?=$item?>. This is, however,
very perl-ish, so I mention it only as a possible way to preserve that
aspect of short tags for template usage. God forbid we start seeing
regular scripts using "=" to mean "echo" :).
As a note, I use exclusively <?php in my templates and also use <?xml to
generate xhtml, so I am very much against per-script enabling of short
tag <? for the annoyance it would introduce of forcing anini_set()at
the top of each template and the bottom as well to be a good citizen and
restore the old value.
To me this sounds more like we were heading towards '<?p' as short of
'<?php' and '<?:' as working erm conflict free form of '<?='.
Best regards,
Marcus
Stanislav Malyshev kirjoitti:
I'd rather see <?php= than having this whole "short_open_tag" thing at
all.Does <?php= work? I though echo shortcut works only with short tags.
No, someone decided it shouldn't be added.
least. Unless we put <?php= in 5.2, which would make me a happy camper,
but might be a trouble for others.
I wouldn't mind. Nor would couple of thousand other people. :)
I'd even use it myself. But I will not EVER enable the damn short tags
again. And won't allow anyone else doing it either. And speaking ofWhat's wrong with short tags, can anybody explain me?
[see below where you ask about the archive search..]
hostile code: ALL code is hostile unless you wrote it yourself. Have you
Not true. You probably use a ton of libraries, never veerifying they
don['t screw up your include path, memory limits, etc.? Why short tags
are so different?
Nobody can set memory_limit in a script during runtime. AFAICT.
Short tags are language SYNTAX issue. That's why it's different.
You don't get any plain error if they're "on" and something doesn't work.
It just doesn't work or misbehaves.
And as you yourself instructed to check for "short_open_tag" in the
archive search: Count how many hits it gives which talk about
problems with it.Can you show which exactly search query you used, so we'd be sure we are
talking about the same thing.
Just plain "short_open_tag" (without the quotes of course :).
Here's the longish url:
http://www.mail-archive.com/find.php?domains=www.mail-archive.com&q=short_open_tag&sa=Search+mailing+lists&sitesearch=www.mail-archive.com&client=pub-7266757337600734&forid=1&channel=2703820358&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23C8C8C8%3BGL%3A1%3BDIV%3A%23CD9685%3BVLC%3A000000%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3AFFFFFF%3BALC%3A006792%3BLC%3A006792%3BT%3A000000%3BGFNT%3A006792%3BGIMP%3A006792%3BFORID%3A11&hl=en
The first hits explain quite well why short_open_tag is bad, mmkay.
--Jani
The first hits explain quite well why short_open_tag is bad, mmkay.
OK, let's see what we have there:
-
Support for my email, skipping.
-
"The web is a rapidly changing market and standards are being
activley evolved. <?php is more compatable with standards on the web
than <? ... and its not about XML document headers."
Then goes for "include XML as template" case. And Rasmus objecting to
short tags being bad code practice. -
Proposal for PHP to not parse <?xml, no explanation why short tags bad.
-
Support for short tags
-
"We should have warned people not to use short tags years ago." no
explanation why. Explaining why <?xml from 2. is not a good idea. -
Bug report on short_open_tag
-
"As the XML community expands and more and more scripting languages
(server and client side) are being designed to interoperate,
cross-language compatability (or at least handling) is required." - same
person as 1. Then:
"The short tag <? is bad form, and shows lazyness. <?php fits the
standard, and its my recommendation that (in version 5 of the product)
the sort tag option is removed."
No explanation why it "shows lazyness" or why it's bad except for
hinting it's somehow bad for handling XML (which it isn't).
-
"I'm -1 on removing short tags, whether now or for PHP5." from Chris.
-
"Not going to happen, please leave this issue alone." from Zeev.
If you have any doubts, "not going to happen" is removal of the short tags. -
"1. Removing (and even disabling by default) short tags is not
necessary for all PHP-community." from Antony.
Should I go deeper? Did we use the same search engine? I'm still missing
explanation why short tags are bad. Since you have obviously found it,
could you do me a favor and quickly summarize at least couple of reasons
- omitting the one being "every application must include XML through
parser" as obviously invalid.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
No explanation why it "shows lazyness" or why it's bad except for
hinting it's somehow bad for handling XML (which it isn't).
See below.
Should I go deeper? Did we use the same search engine? I'm still missing
explanation why short tags are bad.
I gave you the link to one main explanation, the XML specs. Or what
else do you need to explain the problem in the XML context?
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
I gave you the link to one main explanation, the XML specs. Or what
else do you need to explain the problem in the XML context?
I need to explain why XML specs have any relevance to PHP syntax and why
PHP sources should conform to them. Are we coding in XML now? Is
everybody using an XML parser to process PHP code? How XML spec is one
to dictate what PHP syntax is?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
lemme think, PHP is used to generate HTML and XHTML. And often people
have the headers outside of the PHP tags. And some people like to use tools.
But maybe I am wrong. Either way. It appears that nearly every single
person replying is against this. So can we please stop arguing? I don't
think there are more arguemnts coming. And it doesn't look like you are
convincing anyone here.
Maybe instead work on a proposal for something like <?echo, given the
feedback on this thread it looks like people would jumo for it.
marcus
Friday, March 21, 2008, 9:15:33 PM, you wrote:
I gave you the link to one main explanation, the XML specs. Or what
else do you need to explain the problem in the XML context?
I need to explain why XML specs have any relevance to PHP syntax and why
PHP sources should conform to them. Are we coding in XML now? Is
everybody using an XML parser to process PHP code? How XML spec is one
to dictate what PHP syntax is?
Best regards,
Marcus
lemme think, PHP is used to generate HTML and XHTML. And often people
Neither of which require <?. HTML in fact doesn't support it even.
have the headers outside of the PHP tags. And some people like to use tools.
But maybe I am wrong. Either way. It appears that nearly every single
person replying is against this. So can we please stop arguing? I don't
You mean like 3 people that can't even explain why they hate short tags,
but just like me to shut up because their opinion can't be wrong? Yeah,
right.
think there are more arguemnts coming. And it doesn't look like you are
convincing anyone here.
Maybe because these "someone" just can't be convinced by rational
argument. This is really sad that people are willing to sacrifice
interests of the users and the language development for... well, I don't
even know for what. For not admitting they were wrong for once?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Friday, March 21, 2008, 9:37:51 PM, you wrote:
lemme think, PHP is used to generate HTML and XHTML. And often people
Neither of which require <?. HTML in fact doesn't support it even.
have the headers outside of the PHP tags. And some people like to use tools.
But maybe I am wrong. Either way. It appears that nearly every single
person replying is against this. So can we please stop arguing? I don't
You mean like 3 people that can't even explain
I think you should take a step back dude.
think there are more arguemnts coming. And it doesn't look like you are
convincing anyone here.
Maybe because these "someone" just can't be convinced by rational
argument. This is really sad that people are willing to sacrifice
interests of the users and the language development for... well, I don't
even know for what. For not admitting they were wrong for once?
I haven't seen a single technical argument from your side.
Best regards,
Marcus
I haven't seen a single technical argument from your side.
That's just hilarious. I spend entire half-day repeating arguments about
XML and short tags and templates and users and what not - but why bother
if Marcus doesn't even read it? Well, I hope at least somebody reads it.
As for trying to convince people that couldn't care less - I'm close to
give up talking to those.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Wow, noisy...
I've been in the situation where I use php for templating and the short
syntax is much nicer on the eyes. The ability to "flick the switch" for
short tags would be nice.
However, like Steph, I've also been bitten by having a simple xml
declaration in a file with short tags on that completely breaks things.
Parse errors are NOT a good thing. This is why I'd personally prefer
short tags just go poof - having to check all your code so any
appearance of <? is echo'd gets really annoying.
I'd argue that a <?php= shortcut or something similar would help "split
the difference" between the ugliness of the long version and the need to
not break php every time an xml declaration pops up in a file. Even
gettext has a nice _() function shortcut which is less typing than echo
$blah; in every php tag set, and then you wouldn't be fighting with the
potential breakage. The argument that if some new syntax only goes into
5.3, people can't use it doesn't really hold water here because you
wouldn't be able to rely on flipping the short_tags switch before 5.3
either.
I can see both sides of the story, and really don't have a preference -
I'm curious as to the opinions of someone OTHER than Marcus, Stas,
Pierre and Jani ;)
Thanks,
Elizabeth M Smith
Elizabeth M Smith wrote:
I'd argue that a <?php= shortcut or something similar would help "split
the difference" between the ugliness of the long version and the need to
not break php every time an xml declaration pops up in a file.
+1
--
Edward Z. Yang GnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
Wow, noisy...
And having made the commit to the dox before the revert, I'm still
reeling/reading to try and see which way I would go...
I'd argue that a <?php= shortcut or something similar would help "split
the difference" between the ugliness of the long version and the need to
not break php every time an xml declaration pops up in a file. Even
gettext has a nice_()function shortcut which is less typing than echo
$blah; in every php tag set, and then you wouldn't be fighting with the
potential breakage. The argument that if some new syntax only goes into
5.3, people can't use it doesn't really hold water here because you
wouldn't be able to rely on flipping the short_tags switch before 5.3
either.I can see both sides of the story, and really don't have a preference -
I'm curious as to the opinions of someone OTHER than Marcus, Stas,
Pierre and Jani ;)
If you saw ...
<?php $varname; ?>
or
<?php $varname ?>
what would you assume this meant?
From this, I would say it isn't a function call as I would need to add () to it.
It is not an assignment or declaration.
If it was documented that a PHP statement consisting of just a
variable name would echo a string, then I think this would solve all
the problems of readability.
What would you assume a non programmer thought of it? If they were
told "this is how you put a PHP variable into a template" would they
just go with it?
Ok, again, I'm no internals expert.
Maybe the _$varname; would be more pleasing.
On the plus side there is only 1 PHP tag. No matter what happens <?php
will always be the PHP way. I see no need for <?= (and WTF the ASP
ones? I'm late to the PHP - only 5 years - but ...!)
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Elizabeth M Smith wrote:
Wow, noisy...
I've been in the situation where I use php for templating and the short
syntax is much nicer on the eyes. The ability to "flick the switch" for
short tags would be nice.However, like Steph, I've also been bitten by having a simple xml
declaration in a file with short tags on that completely breaks things.
Parse errors are NOT a good thing. This is why I'd personally prefer
short tags just go poof - having to check all your code so any
appearance of <? is echo'd gets really annoying.I'd argue that a <?php= shortcut or something similar would help "split
the difference" between the ugliness of the long version and the need to
not break php every time an xml declaration pops up in a file. Even
gettext has a nice_()function shortcut which is less typing than echo
$blah; in every php tag set, and then you wouldn't be fighting with the
potential breakage. The argument that if some new syntax only goes into
5.3, people can't use it doesn't really hold water here because you
wouldn't be able to rely on flipping the short_tags switch before 5.3
either.I can see both sides of the story, and really don't have a preference -
I'm curious as to the opinions of someone OTHER than Marcus, Stas,
Pierre and Jani ;)
There are a bunch of factors here. In the end it comes down to the
purists vs. the pragmatists. You all know where I fall on that one.
<?php is for the purists and <? and <?= still exists for the pragmatists.
Now, someone mentioned <?php= which I am completely against as it breaks
the purist side. A PI tag is defined as <?<label><whitespace> and I am
pretty sure the PI label names can't contain '='. <?php was added and
adopted in order to be correct, let's not break that correctness.
Most of the arguments I have seen are basically saying <? is evil and it
shouldn't even exist, but that isn't the current question. It does
exist, and we aren't removing it, so the only real argument here is the
WTF factor introduced by code that is able to enabled or disable these
tags on the fly. That's the one and only valid argument I have seen.
Whether or not PHP code can be validated with xmllint and whether or not
<? is valid xml, which it obviously isn't, is completely beside the
point. We all know that when you use <? you are not XML-compliant. And
for the vast majority that's ok. XHTML is dead because IE, which is
unfortunately the dominant browser has never and never will support
XHTML. Yes, you can hack it and serve up XHTML with an HTML mime type
and apply various hacks to sort of almost maybe sometimes get it to work
in IE, but nobody who does any serious web development uses XHTML for
sites that have wide audiences.
So, we are down to a very simple decision. Does the added WTF factor of
dynamically changing short_open_tags outweigh the benefits to the folks
using <?-based templates?
My view is that people want templating. As much as I hate the concept,
and have always been very vocal about that, people want simpler
templating tags. They will even go as far as parsing files and
generating PHP code on every single request in order to use {blah}
instead of <?php blah() ?>. The fact that people are willing to take an
order of magnitude performance hit for syntactic sugar is baffling to
me, but just look at all the templating systems out there. And yes, I
know there are other reasons to use templating such as restricting the
feature set for untrusted template writers, etc. but you'd be surprised
how many people just want to type less and have their tags be prettier.
Getting these folks to switch to <?blah()?> is a win for performance
and sanity in my book. Yes, it isn't a full victory, but it is still a win.
In order for a templating system to use <? they have to have
short_open_tag on for the entire system. By allowing them to only apply
the short_open_tags to certain parts of their code it means that they
will write correct <?php business logic and only use the short_open_tags
for the actual included template files. Again, not a full victory, but
a win for us in the sense that the actual PHP code in their application
will be using <?php everywhere. They can't get lazy and use short_tags
in their business logic because it won't work due to limiting the
short_open_tags to just the templates.
I recognize the WTF factor of dynamically changing the setting, but
frankly since it can already be changed per-dir from one request to the
next on the same server, I really don't see the incremental WTF factor
as being very high.
Consider the fact that:
<?php
virtual('templates/main.php');
?>
and
<?php
ini_set('short_open_tag',true);
include 'templates/main.php';
ini_set('short_open_tag',false);
?>
Will actually do about the same thing in the sense that the top-level
script can run with short_open_tag turned off and the main.php script
can run with short_open_tag enabled. The first version requires that
you configure your Apache to enable short_open_tag for the templates/
directory, while the second lets you do it from the PHP level. The
first suffers from being extremely slow and it isn't obvious that
scripts in templates/ operate under different rules. The second is much
faster and it is more obvious what is happening.
-Rasmus
Hi Rasmus,
Will actually do about the same thing in the sense that the top-level
script can run with short_open_tag turned off and the main.php script
can run with short_open_tag enabled. The first version requires that
you configure your Apache to enable short_open_tag for the templates/
directory, while the second lets you do it from the PHP level. The
first suffers from being extremely slow and it isn't obvious that
scripts in templates/ operate under different rules. The second is much
faster and it is more obvious what is happening.
as a conclusion from my point of view, I don't think it's possible to
bring anything new to this dicsussion:
-1 for the patch (revert)
+1 to actually deprecate short tags
+1 to remove them in HEAD
That's not asked but let clear this problem once and for all.
Cheers,
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Friday, March 21, 2008 8:30 PM
To: Rasmus Lerdorf
Cc: Elizabeth M Smith; internals@lists.php.net
Subject: Re: [PHP-DEV] short_open_tagHi Rasmus,
Will actually do about the same thing in the sense that the top-level
script can run with short_open_tag turned off and the main.php script
can run with short_open_tag enabled. The first version requires that
you configure your Apache to enable short_open_tag for the templates/
directory, while the second lets you do it from the PHP level. The
first suffers from being extremely slow and it isn't obvious that
scripts in templates/ operate under different rules. The second is much
faster and it is more obvious what is happening.as a conclusion from my point of view, I don't think it's possible to
bring anything new to this dicsussion:-1 for the patch (revert)
+1 to actually deprecate short tags
+1 to remove them in HEADThat's not asked but let clear this problem once and for all.
Cheers,
Hi,
I'm new to the internals, but I've been reading you for months... now, let me
ask,
Are there any security issues with short tags?
Is it really harder for the interpreter to have them enabled?
Is the short tags parsing code too hard to maintain?
Do they create a performance hit?
Do they create bad habits, why?
Does the patch for ini_set create a performance issue?
What ACTUAL situation makes you hate short tags? What code are you using to do
what such that you find short tags being evil?
Isn't it that you just don't like them, or don't like reading them in PHP code?
I personally hate <? ?>, but I like and use <?= ?>, it's just much more readable
and concise than <?php echo ... ?>. What if the parser would ignore <?xml, or
<?whatever except <?php and <?=. I don't know you guys, but every templating
system I've had to deal with is using them and every MVC framework out there is
using short tags for the views. And they only represent an issue if you have
some XML code you send through the PHP parser, and you can always use a
global/per-dir setting if you just don't like them.
+1 for the patch (if it doesn't create a performance or maintainability issue)
+1 to keep short tags into PHP (deprecate them if you want, but only remove them
in PHP 7 and provide a suitable alternative)
Regards,
Rob
Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
Email: info@bestplace.net | MSN Chat: best@bestplace.net | SKYPE: bestplace |
Web: bestplace.biz | Web: seo-diy.com
Elizabeth M Smith wrote:
Wow, noisy...
I've been in the situation where I use php for templating and the short
syntax is much nicer on the eyes. The ability to "flick the switch" for
short tags would be nice.However, like Steph, I've also been bitten by having a simple xml
declaration in a file with short tags on that completely breaks things.
Parse errors are NOT a good thing. This is why I'd personally prefer
short tags just go poof - having to check all your code so any
appearance of <? is echo'd gets really annoying.I'd argue that a <?php= shortcut or something similar would help "split
the difference" between the ugliness of the long version and the need to
not break php every time an xml declaration pops up in a file. Even
gettext has a nice_()function shortcut which is less typing than echo
$blah; in every php tag set, and then you wouldn't be fighting with the
potential breakage. The argument that if some new syntax only goes into
5.3, people can't use it doesn't really hold water here because you
wouldn't be able to rely on flipping the short_tags switch before 5.3
either.I can see both sides of the story, and really don't have a preference -
I'm curious as to the opinions of someone OTHER than Marcus, Stas,
Pierre and Jani ;)There are a bunch of factors here. In the end it comes down to the
purists vs. the pragmatists. You all know where I fall on that one. <?php
is for the purists and <? and <?= still exists for the pragmatists.Now, someone mentioned <?php= which I am completely against as it breaks
the purist side. A PI tag is defined as <?<label><whitespace> and I am
pretty sure the PI label names can't contain '='. <?php was added and
adopted in order to be correct, let's not break that correctness.Most of the arguments I have seen are basically saying <? is evil and it
shouldn't even exist, but that isn't the current question. It does exist,
and we aren't removing it, so the only real argument here is the WTF
factor introduced by code that is able to enabled or disable these tags on
the fly. That's the one and only valid argument I have seen. Whether or
not PHP code can be validated with xmllint and whether or not <? is valid
xml, which it obviously isn't, is completely beside the point. We all
know that when you use <? you are not XML-compliant. And for the vast
majority that's ok. XHTML is dead because IE, which is unfortunately the
dominant browser has never and never will support XHTML. Yes, you can
hack it and serve up XHTML with an HTML mime type and apply various hacks
to sort of almost maybe sometimes get it to work in IE, but nobody who
does any serious web development uses XHTML for sites that have wide
audiences.So, we are down to a very simple decision. Does the added WTF factor of
dynamically changing short_open_tags outweigh the benefits to the folks
using <?-based templates?My view is that people want templating. As much as I hate the concept,
and have always been very vocal about that, people want simpler templating
tags. They will even go as far as parsing files and generating PHP code
on every single request in order to use {blah} instead of <?php blah() ?>.
The fact that people are willing to take an order of magnitude performance
hit for syntactic sugar is baffling to me, but just look at all the
templating systems out there. And yes, I know there are other reasons to
use templating such as restricting the feature set for untrusted template
writers, etc. but you'd be surprised how many people just want to type
less and have their tags be prettier. Getting these folks to switch to
<?blah()?> is a win for performance and sanity in my book. Yes, it isn't
a full victory, but it is still a win.In order for a templating system to use <? they have to have
short_open_tag on for the entire system. By allowing them to only apply
the short_open_tags to certain parts of their code it means that they will
write correct <?php business logic and only use the short_open_tags for
the actual included template files. Again, not a full victory, but a win
for us in the sense that the actual PHP code in their application will be
using <?php everywhere. They can't get lazy and use short_tags in their
business logic because it won't work due to limiting the short_open_tags
to just the templates.I recognize the WTF factor of dynamically changing the setting, but
frankly since it can already be changed per-dir from one request to the
next on the same server, I really don't see the incremental WTF factor as
being very high.Consider the fact that:
<?php
virtual('templates/main.php');
?>and
<?php
ini_set('short_open_tag',true);
include 'templates/main.php';
ini_set('short_open_tag',false);
?>Will actually do about the same thing in the sense that the top-level
script can run with short_open_tag turned off and the main.php script can
run with short_open_tag enabled. The first version requires that you
configure your Apache to enable short_open_tag for the templates/
directory, while the second lets you do it from the PHP level. The first
suffers from being extremely slow and it isn't obvious that scripts in
templates/ operate under different rules. The second is much faster and
it is more obvious what is happening.
Ok here's a stupid suggestion.
Is it at all possible to turn off (for all time) short_tags in php.ini BUT
allow scripts that want to use short-tags to explicitly use them via
ini_set()?
It might mean a lot of re-thinking... and yes I do know it's not currently
an option :)
- Steph
Rasmus Lerdorf wrote:
There are a bunch of factors here. In the end it comes down to the
purists vs. the pragmatists. You all know where I fall on that one.
<?php is for the purists and <? and <?= still exists for the pragmatists.Now, someone mentioned <?php= which I am completely against as it breaks
the purist side. A PI tag is defined as <?<label><whitespace> and I am
pretty sure the PI label names can't contain '='. <?php was added and
adopted in order to be correct, let's not break that correctness.Most of the arguments I have seen are basically saying <? is evil and it
shouldn't even exist, but that isn't the current question. It does
exist, and we aren't removing it, so the only real argument here is the
WTF factor introduced by code that is able to enabled or disable these
tags on the fly. That's the one and only valid argument I have seen.
I think I'm a purist pragmatist ;)
I HAVE been moving to <?php but I've still got a lot of code that is <?.
Having just taken a close look at the differences, the main thing is that all
the old code has lots of in line html and adding 'php' everywhere ( actually
4500 hits ) will make it even more difficult to read. However I am the only
person using that code, and simply remembering to switch back on short tags on
a new installation allows the old stuff to work.
All my new work is going via bitweaver and I was a little surprised to find
only 10 <? entries in the whole of the code base, since it's using smarty to
pump out the html. And most of those seem to be either mistakes - '<? php' or
are actually in SQL - and wrong :)
An hour ago I would have said I needed <? but now I'm more than happy that
since I am being dragged the right way by the other bitweaver members - <?
will become a thing of the past for me. HOWEVER quick and dirty pages will no
doubt come out of the shop here simply because there are so many quite complex
pages in the archive and I'm not sure a global convert - while easy to do - is
appropriate.
Bottom line. Global does not work for me - yet, directory level does and I
can't see any logical reason now for switching on and off at will. If it's in
a short tag directory that will do for me - now I just need to actually do that :)
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Nobody can set memory_limit in a script during runtime. AFAICT.
Why? It's INI_ALL. So is, for example, include_path.
Short tags are language SYNTAX issue. That's why it's different.
You don't get any plain error if they're "on" and something doesn't work.
It just doesn't work or misbehaves.
In 99.999% of cases you'd get parse error on first <?xml, i.e. very
first line of the file. I have yet to see any other context where short
tags wouldn't work. So I don't see - what exactly would "not work or
misbehave" without giving an error? Can you produce any example of
application or other real code that would silently misbehave with short
tags on but behave OK with short tags off?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi Stas,
In 99.999% of cases you'd get parse error on first <?xml, i.e. very first
line of the file. I have yet to see any other context where short tags
wouldn't work. So I don't see - what exactly would "not work or misbehave"
without giving an error? Can you produce any example of application or
other real code that would silently misbehave with short tags on but
behave OK with short tags off?
I had at least five PHP/XML applications that did just that during the PHP 5
coding contest at Zend back in 5.0 days... Zeev asked me at the time to
explain it more fully, and I sincerely regret never having made the time to
look into it properly.
And no I don't still have those applications on my laptop. Sorry. But it's
as a result of working on that contest that I'm against short-tags full
stop - I still think they should've been deprecated from 5.0 on.
Not good evidence I know, but that's my tuppence-worth on the subject.
- Steph
Can you produce any example of
application or other real code that would silently misbehave with short
tags on but behave OK with short tags off?
Embedding PHP in a SVG (XML) file to generate a batch of images with
small differences. In my case web buttons with different labels and
icons. This way I have only one SVG file with some PHP code inside (a
few echos) that is included by an external PHP file. The PHP script
loops through an array of strings (labels and absolute path to icons)
and save to the filesystem as many SVGs as necessary. That saves me a
lot of work when I have to create a some more new buttons.
I don't mean short_open_tag should be banned or not, but thats one
possible example for your request.
best regards,
iGor.
I'd rather see <?php= than having this whole "short_open_tag" thing at all.
Does <?php= work? I though echo shortcut works only with short tags.
<?php= is not much worse than <?= so it'd be OK with me. Downside would
be template systems couldn't use it until 5.3 is widely deployed - which
means no template system can use it as standard for about 2-3 years at
least. Unless we put <?php= in 5.2, which would make me a happy camper,
but might be a trouble for others.I'd even use it myself. But I will not EVER enable the damn short tags
again. And won't allow anyone else doing it either. And speaking ofWhat's wrong with short tags, can anybody explain me?
The main reason is that they are not valid processing instructions.
See http://www.w3.org/TR/REC-xml/#sec-pi
Cheers,
The main reason is that they are not valid processing instructions.
See http://www.w3.org/TR/REC-xml/#sec-pi
Great, they are also probably not valid S-expressions and not valid
phrases in Mandarin. Why they are bad because of that? Is there any
requirement for them to be?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Friday, March 21, 2008, 9:05:17 PM, you wrote:
The main reason is that they are not valid processing instructions.
See http://www.w3.org/TR/REC-xml/#sec-pi
Great, they are also probably not valid S-expressions and not valid
phrases in Mandarin. Why they are bad because of that? Is there any
requirement for them to be?
The argument being?
Best regards,
Marcus
Great, they are also probably not valid S-expressions and not valid
phrases in Mandarin. Why they are bad because of that? Is there any
requirement for them to be?The argument being?
Why they are bad because of that? Is there any requirement for them to be?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
The main reason is that they are not valid processing instructions.
See http://www.w3.org/TR/REC-xml/#sec-piGreat, they are also probably not valid S-expressions and not valid
phrases in Mandarin. Why they are bad because of that? Is there any
requirement for them to be?
PHP works more and more in a multi cultural environment (php, jsp,
xml, etc.). One of the goals of a standard is to avoid conflicts,
buggy behavior or system specific features. PHP works with XML in many
cases, xhtml growing usage is one good example. I'm very surprised to
have to discuss this problem once again in this list.
Cheers,
PHP works more and more in a multi cultural environment (php, jsp,
xml, etc.). One of the goals of a standard is to avoid conflicts,
Great. So let's see when there could be a conflict. Only way there could
be a conflict is when XML is included as PHP source. Now, how frequently
one really needs to do that?
buggy behavior or system specific features. PHP works with XML in many
cases, xhtml growing usage is one good example. I'm very surprised to
have to discuss this problem once again in this list.
You sound like it was discussed and the decision was in your favor.
Well, it wasn't - read the summary I just made from the archives. So if
you want to declare "case closed" - fine, but it's closed in favor of
short tags.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Friday, March 21, 2008, 9:32:48 PM, you wrote:
PHP works more and more in a multi cultural environment (php, jsp,
xml, etc.). One of the goals of a standard is to avoid conflicts,
Great. So let's see when there could be a conflict. Only way there could
be a conflict is when XML is included as PHP source. Now, how frequently
one really needs to do that?
There is also an issue when I want to verify my stuff using XML tools.
Best regards,
Marcus
There is also an issue when I want to verify my stuff using XML tools.
One can't really verify PHP code with XML tools, so what exactly are you
verifying - could you explain more on that?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
since when can I not verify that my general HTML/XHTML structure is valid?
This is especially valid in template systems as you mentioned earlier.
Because in fact PHP is a tmeplate system for HTML/XHTML after all. So as
long as I only do easy stuff and avoid generating tags inside php I get
valid XML source.
marcus
Friday, March 21, 2008, 9:49:55 PM, you wrote:
There is also an issue when I want to verify my stuff using XML tools.
One can't really verify PHP code with XML tools, so what exactly are you
verifying - could you explain more on that?
Best regards,
Marcus
Hi!
since when can I not verify that my general HTML/XHTML structure is valid?
The question is since when PHP code has any XML structure?
This is especially valid in template systems as you mentioned earlier.
OK, so you are verifying templates. Great. Obviously, if you use XML
templates (with PHP being Web language, this is rather unusual use case,
but OK), you are not using short tags, so it's OK. However, for people
having HTML templates, it still would be OK to verify them with HTML
tools unless you have tools that OK with <?php but can't support <?=.
Are there such tools?
Because in fact PHP is a tmeplate system for HTML/XHTML after all. So as
If it were only template system, we'd all use short tags as all other
templates do - take Ruby, Perl::Mason, ASP or JSP, any of those have
echo shortcut. None of those are too bothered if it works with XML
parser either, as far as I can see.
long as I only do easy stuff and avoid generating tags inside php I get
valid XML source.
Wait, so it's not only special case of templates - XML - but special
case of special case - only templates generating very special kind of
content. So why the whole language syntax should conform this tiny
subset of all use cases? I'd think it is much better to do what users
obviously need - since everybody does it, including all popular template
systems bare none - and support short tags.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Friday, March 21, 2008, 10:11:24 PM, you wrote:
Hi!
since when can I not verify that my general HTML/XHTML structure is valid?
The question is since when PHP code has any XML structure?
This is especially valid in template systems as you mentioned earlier.
OK, so you are verifying templates. Great. Obviously, if you use XML
templates (with PHP being Web language, this is rather unusual use case,
but OK), you are not using short tags, so it's OK. However, for people
having HTML templates, it still would be OK to verify them with HTML
tools unless you have tools that OK with <?php but can't support <?=.
Are there such tools?
<?php is a valid PI.
<?= is not
This was discussed several times already and Pierre put you directly onto
its definition. What more can we say? I think we have a valid technical
argument here, where you seem to simply wanting to save a few key strokes.
Best regards,
Marcus
This was discussed several times already and Pierre put you directly onto
its definition. What more can we say? I think we have a valid technical
You obviously think so, but it doesn't automatically makes it valid.
Explaining again: PHP code needs to conform to XML standard only if
you have files that need to be both valid PHP and valid XML. Only
files I can imagine that need to be both valid PHP and valid XML are XML
templates that are passed through PHP parser. It is very rare use case -
most of templates are HTML and not XML - and it can be supported even
better with my proposal, since with it you can haver both XML
templates and HTML templates with short tags in the same application,
without needing any external configuration - while without it you can
have only one working, even with configuration.
argument here, where you seem to simply wanting to save a few key strokes.
Sounds like you miss most of what I write, but I will try again, in hope
this time I manage to squeeze it through. I do not "simply want to save
keystrokes", I want to enable PHP template systems to have functionality
that:
- Is present in every popular templating system, including RoR, ASP,
JSP, Perl::Mason and probably countless others. - Makes PHP templates easy to read even for person not knowing PHP
syntax, easy to write and and easy to parse visually.
Now, I see enabling runtime <?= (I couldn't care less for <?) as best
way to do it, since it allows to do the above without permanently
disabling even the very rare XML parsing case - you can easily do
templating system that supports both. If there's better way (and
<?phpecho isn't since it does not do anything but - yes! - saving one
keystroke), then I am willing to consider it.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Friday, March 21, 2008, 8:11:04 PM, you wrote:
Hi!
For me the largest issue is infact late enabling of short tags at run time.
The issue tracks down to the issue where peole might use code that enables
short open tags but forgets to disable that. Now why might I rely on short
I think this case is very unlikely. The use case for this feature is
template system, written in long-tags style, but using short-tags
notation for PHP templates. To compare:
My name is <?= $name ?> and I am <?= $age ?> years old.
My name is <?php echo $name; ?> and I am <?php echo $age; ?> years old.
I think there's little doubt people - especially non-programmer people
like designers - would have much less trouble understanding and writing
first notation than second notation. If you compare larger, more complex
templates, the difference in readability is even bigger. And having code
easy to work with is one of the reasons people do PHP.
But the non programmers don't understand <?=, $ and ?> either. And instea
of promoting <?= we should probably add <?echo which would be compatible
to XML.
Now, in a template system, it is really hard to imagine that template
system creator would be so sloppy as to intend to write code like:
setShortTags();
include $user_template;
resetShortTags();
and somehow "forget" to write the last function. That would require
extreme absent-mindedness on developer's part and you definitely should
steer clear of template systems written by such people. However, for
real template systems I know - they are written by very smart people,
and actually these people support this capability, as it allows them to
use nice syntax in templates without requiring any system configuration
(which may be unavailable or incompatible with other code).
open tags being disabled is another question of course. Years ago when we
This is very important question, since the only known case of why it
might be important is when you use XML as template by including it
directly through PHP parser. I don't think I would be mistaken if I say
this is extremely rare use case. Actually, I'm not sure there's even one
of common applications - like known CMSes, frameworks, blog platforms,
e-commerce platforms, etc. - that can not work with short tags. Can you
name which ones can't?
Again, I consider the concept of "accidentally enabling" sort tags very
improbable, but even if it somehow happened - IMO it would not be a
problem except in some very rare use cases.
last discussed whether we should discourage them the conclusion was that
not many people rely on them being off. Today many people have php code
And if you look at the discussion, there were opinions - including
Zeev's - that there's nothing wrong with shorts tags in general, only in
some rare use cases.
That is more than 5 years ago though.
short syntactical sugar when all it does is saving keystrokes. With short
open tags the argument usually simply is that '<?=$bla?>' is shorther than
writing '<?php echo $bla:?>'. But then again the former is much harder to
spot in manual written code. And for generated code it doesn't matter at
I have hard time figuring out a use case when you need to "spot" this in
your code - and, indeed, have one in your code at all, unless it is a
template. In a template, <?= is much better and with any decent editor,
very easy to spot.
Nope, the shorter the sequence to look for the harder.
all. That said I am against short open tags. And given my first part. I do
not want to deal with code that does 'php_ini_set("short_open_tags", 0);'
after every single include or require statement.
You do not need to deal with this code, and there's absolutely no reason
But I do not have to use something is no reason to add a function.
And on top of that - if you are still concerned, you always could do
php_admin_value which IIRC blocks setting values by user.
But I don't want to add more stuff to make sure my stuff works. I want it
infact easier with less configurations.
Best regards,
Marcus
Hi!
But the non programmers don't understand <?=, $ and ?> either. And instea
They do. "Non programmer" != "idiot".
of promoting <?= we should probably add <?echo which would be compatible
to XML.
See my previous mail on that.
That is more than 5 years ago though.
OK, so?
But I do not have to use something is no reason to add a function.
I never brought it as a reason to add. The reason is the use case we
already discussed.
But I don't want to add more stuff to make sure my stuff works. I want it
infact easier with less configurations.
In real use cases, you won't need any configurations at all. In
imaginary use case where you are beset by hostile includes that are
determined to ruin your environment and incompetent library writers that
can't write 3 lines of code, but you must use their libraries, and on
top of that you absolutely must to include XML files into the same
application - in this imaginary case you still have very easy solution
that allows you to go back to pre-patch state. I wish all patches could
be reverted as easily when needed.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
And if you look at the discussion, there were opinions - including
Zeev's - that there's nothing wrong with shorts tags in general, only in
some rare use cases.
http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262&r2=1.263
guess who made that commit...
-Hannes
http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262&r2=1.263
guess who made that commit...
I wish I remembered what the rationale for that was, but of course I
don't. Anyway, in 7 years there might be a bit of a change in how people
use PHP, and that of course doesn't support the point of short tags
being evil in general.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262&r2=1.263
guess who made that commit...I wish I remembered what the rationale for that was, but of course I
don't. Anyway, in 7 years there might be a bit of a change in how people
use PHP, and that of course doesn't support the point of short tags
being evil in general.
Yeah, there has been a huge change. A good chunk of that change is XML.
-Hannes
Yeah, there has been a huge change. A good chunk of that change is XML.
XML as "parsing XML and working with DOM", not XML as "putting XML
through PHP parser". It is very important to understand that no short
tags would ever cause you any problems with any XML unless you put
that XML through PHP parser - which having DOM, SimpleXML, etc. isn't
really that needed. Less then ever, I'd say.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
well, any XML tool seeing '<?=' or '<? ' would error out as that is
invalid XML.
Friday, March 21, 2008, 10:26:52 PM, you wrote:
Yeah, there has been a huge change. A good chunk of that change is XML.
XML as "parsing XML and working with DOM", not XML as "putting XML
through PHP parser". It is very important to understand that no short
tags would ever cause you any problems with any XML unless you put
that XML through PHP parser - which having DOM, SimpleXML, etc. isn't
really that needed. Less then ever, I'd say.
Best regards,
Marcus
Yeah, there has been a huge change. A good chunk of that change is XML.
XML as "parsing XML and working with DOM", not XML as "putting XML
through PHP parser".
Please (OH! Please!!!) read our answers, read the specs and understand
that many of us (if not the majority) have to work with xhtml or XML.
It is very important to understand that no short
tags would ever cause you any problems with any XML unless you put
that XML through PHP parser - which having DOM, SimpleXML, etc. isn't
really that needed. Less then ever, I'd say.
Ok, can you at least try what you affirm?
Some tips:
I often use xmllint or other w3c tools to verify that my xml/xhtml
code is valid, before being parsed by php:
Take this file:
<?xml version="1.0" encoding="utf-8" ?>
<foo>
<? echo "bar"; ?>
</foo>
and run it through xmllint.
Can we now stop this discussion and revert this patch?
Thanks for your understanding, there is no more argument on any side
and the decision is obvious (by the voices and by the arguments).
Cheers,
Please (OH! Please!!!) read our answers, read the specs and understand
that many of us (if not the majority) have to work with xhtml or XML.
Working with XML does not requires putting XML through PHP parser. Even
if it did, with my patch it works better than without - it allows to
have both HTML templates and XML without needing even to touch
configurations.
I often use xmllint or other w3c tools to verify that my xml/xhtml
code is valid, before being parsed by php:
Right, so you are using XML templates. Don't do short tags then. Many
other people, however, use HTML templates, and they are OK and actually
want to use short tags.
Thanks for your understanding, there is no more argument on any side
and the decision is obvious (by the voices and by the arguments).
No, it is not obvious, unless you take "obvious" to mean "agreeing with
you".
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I often use xmllint or other w3c tools to verify that my xml/xhtml
code is valid, before being parsed by php:Right, so you are using XML templates. Don't do short tags then. Many
other people, however, use HTML templates, and they are OK and actually
want to use short tags.
Don't personalize this discussion, it is not me but many. Don't
ignore this fact, thanks.
Cheers,
Take this file:
<?xml version="1.0" encoding="utf-8" ?>
<foo>
<? echo "bar"; ?>
</foo>and run it through xmllint.
Can we now stop this discussion and revert this patch?
Take this file:
<?xml version="1.0" encoding="utf-8" ?>
<foo>
<?php echo "<bar>"; ?>
</foo>
and run it through your xmllint.
Passes right? Does that mean its valid xml/xhtml on the flip side? No,
it wont pass.
Is XML Spec compliancy a goal of the PHP Project?
-ralph
Take this file:
<?xml version="1.0" encoding="utf-8" ?>
<foo>
<? echo "bar"; ?>
</foo>and run it through xmllint.
Can we now stop this discussion and revert this patch?
Take this file:
<?xml version="1.0" encoding="utf-8" ?>
<foo>
<?php echo "<bar>"; ?>
</foo>and run it through your xmllint.
Passes right? Does that mean its valid xml/xhtml on the flip side? No,
it wont pass.Is XML Spec compliancy a goal of the PHP Project?
It was an answer to a wrong claim. Don't create wrong conclusions out
of my post, thanks.
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Hi Ralph, Pierre, everybody,
Am Samstag, den 22.03.2008, 01:23 +0100 schrieb Pierre Joye:
Take this file:
<?xml version="1.0" encoding="utf-8" ?>
<foo>
<? echo "bar"; ?>
</foo>and run it through xmllint.
That's exactly the point, thanks Ralph. It makes absolutely no sense
validating XML documents containing PHP instructions before the
instructions have been processed as the instructions may - obviously -
change the state of the document (e.g. . So a much more sensible QA
practice is to generate the process the template and validate it after
processing (at least in the development stage). At this time, no matter
which tags have been used, and only at this time, it is possible to
determine whether a document can be counted valid or not.
Example 1 (not valid before processing):
<test>
<element value="<?php echo htmlentities($foo);?>"/>
</test>
Example 2 (valid before processing but not after):
<test>
<?php echo "<element/>";?>
</test>
Example 3 (valid before an after processing):
<test>
<element><?php echo htmlentities($value);?></element>
</test>
I've picked three random use cases. Only one of them can be successfully
validated before processing.
Rasmus pointed it out before, people are using short tags, because they
want to save keystrokes and increase readability. More verbose code
(using temporary variables, etc. pp.) might be better in business logic
but the quality of a template rises and sinks with the size of its
instructions. This is why people do use Smarty ({foreach from=$array
item=item} is shorter than <?php if (isset($array) and is_array($array))
{ foreach ($array as $item) { ... }}) and similiar template engines.
Providing the infrastructure to enable/disable short tags per runtime
allows people to better define their API, in this case the API for
templating as they can define "the only point where one may use short
tags, are the templates". Currently, if people want short tags, and they
want to use it (see Solar_View or Zend_View from the Solar resp. Zend
Framework), the only way to use short tags is to globally enable them.
So please, just leave the patch in, and do not use short tags, if you
dislike them.
cu, Lars
Hi,
Hi Ralph, Pierre, everybody,
Am Samstag, den 22.03.2008, 01:23 +0100 schrieb Pierre Joye:
Take this file:
<?xml version="1.0" encoding="utf-8" ?>
<foo>
<? echo "bar"; ?>
</foo>and run it through xmllint.
That's exactly the point, thanks Ralph. It makes absolutely no sense
validating XML documents containing PHP instructions before the
instructions have been processed
Read: Code validation (like in pre commit rules), is one common usage.
Think about xml being XML data or HTML. Nothing prevents one to write
valid (x)html in a valid xml format.
And again this exact example was a proof to a wrong claim, it has to
be extended to be applicable to a real life context. This small but
obvious example is not a real life context but only (and only!) the
proof that Stan's claim was wrong, period.
Cheers,
Hello Pierre,
Am Samstag, den 22.03.2008, 13:17 +0100 schrieb Pierre Joye:
[...]
Read: Code validation (like in pre commit rules), is one common usage.
Where? I've just never seen any project that does XML validation on XML
templates as a pre-commit rule.
Think about xml being XML data or HTML. Nothing prevents one to write
valid (x)html in a valid xml format.
Again: there is no point in validating at a pre-interpreted XML files
(if they contain interpretable code).
And again this exact example was a proof to a wrong claim, it has to
be extended to be applicable to a real life context.
Making the example longer (aka "applicable to a real life context"?)
would not change the common characteristics. My claim is, that a
pre-interpreted XML file with PHP instructions can't be reliably
validated anyway, so their is no reason bothering with it.
This small but obvious example is not a real life context but only
(and only!) the proof that Stan's claim was wrong, period.
I'm not sure to which claim you are referring, but I'm not Stas advocate
so this might be true :)
cu, Lars
Hi Lars,
Providing the infrastructure to enable/disable short tags per runtime
allows people to better define their API, in this case the API for
templating as they can define "the only point where one may use short
tags, are the templates". Currently, if people want short tags, and they
want to use it (see Solar_View or Zend_View from the Solar resp. Zend
Framework), the only way to use short tags is to globally enable them.
So please, just leave the patch in, and do not use short tags, if you
dislike them.
It seems to be very hard to understand that it is not so simple. If
this feature is added, every library/module write will have to take
care of the short tags if they like to work smoothly in any unknown
configuration at runtime. The check is now done (in many cases) during
the installation phase and the install script asks the user to disable
the short tags to install and run the application or library. If
Zend_View or Solar_View use short tags (even worst if they require
them), they must be the exceptions in any recent/decent frameworks.
The problem with this feature is that the setting can be changed at
runtime, anytime. It is yet another pain a la magic quotes GPC and
other things like register globals. You said:
"the only way to use short tags is to globally enable them."
That's not the case anymore with this patch and that's why we don't like it...
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Hi Pierre,
Am Samstag, den 22.03.2008, 13:27 +0100 schrieb Pierre Joye:
[...]
It seems to be very hard to understand that it is not so simple. If
this feature is added, every library/module write will have to take
care of the short tags if they like to work smoothly in any unknown
configuration at runtime. The check is now done (in many cases) during
the installation phase and the install script asks the user to disable
the short tags to install and run the application or library. If
Zend_View or Solar_View use short tags (even worst if they require
them), they must be the exceptions in any recent/decent frameworks.
They do not require them, as their "templating" mechanism is as simple
as including a PHP file. So it depends on the runtime settings if this
PHP file can be evaluated properly.
The problem with this feature is that the setting can be changed at
runtime, anytime. It is yet another pain a la magic quotes GPC and
other things like register globals. You said:
Normally, it doesn't matter if short tags are enabled or not. In some
cases it is important to have them disabled (the XML example) and in
some cases it is important to have them enabled (the simple templating
example). So the component which does XML validation can simply disable
it while the templating component enables it. The rest should simply
work with both.
"the only way to use short tags is to globally enable them."
That's not the case anymore with this patch and that's why we don't
like it...
I understood that. And that's the reason I like the patch :)
cu, Lars
Hello Lars, Stas,
you can already do all you want. We do not have to make it more complex
at all. Ini setting short_open_tags is defined as PHP_INI_PER_DIR, so all
you guys have to do is provide the right configuration, that's all. And if
you guys ship your templates then simply remember to ship the configuration
in the template dirs as well (.thaccess). In PHP 5.3 you can even do that
per dir in php.ini.
marcus
Saturday, March 22, 2008, 1:36:36 PM, you wrote:
Hi Pierre,
Am Samstag, den 22.03.2008, 13:27 +0100 schrieb Pierre Joye:
[...]It seems to be very hard to understand that it is not so simple. If
this feature is added, every library/module write will have to take
care of the short tags if they like to work smoothly in any unknown
configuration at runtime. The check is now done (in many cases) during
the installation phase and the install script asks the user to disable
the short tags to install and run the application or library. If
Zend_View or Solar_View use short tags (even worst if they require
them), they must be the exceptions in any recent/decent frameworks.
They do not require them, as their "templating" mechanism is as simple
as including a PHP file. So it depends on the runtime settings if this
PHP file can be evaluated properly.
The problem with this feature is that the setting can be changed at
runtime, anytime. It is yet another pain a la magic quotes GPC and
other things like register globals. You said:
Normally, it doesn't matter if short tags are enabled or not. In some
cases it is important to have them disabled (the XML example) and in
some cases it is important to have them enabled (the simple templating
example). So the component which does XML validation can simply disable
it while the templating component enables it. The rest should simply
work with both.
"the only way to use short tags is to globally enable them."
That's not the case anymore with this patch and that's why we don't
like it...
I understood that. And that's the reason I like the patch :)
cu, Lars
Best regards,
Marcus
you can already do all you want. We do not have to make it more complex
at all. Ini setting short_open_tags is defined as PHP_INI_PER_DIR, so all
you guys have to do is provide the right configuration, that's all. And if
Ok, here we go again: this setting is needed to enable people to work
BOTH with short tag templates AND in context when short tags can not be
turned on by system configuration (by technical, administrative or
whatever reason). We want to make it work WITHOUT requiring to change
system configuration, exactly for the reason that it would work in ANY
system configuration and WOULD NOT require any administrative work.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi Stas,
you can already do all you want. We do not have to make it more complex
at all. Ini setting short_open_tags is defined as PHP_INI_PER_DIR, so all
you guys have to do is provide the right configuration, that's all. And
ifOk, here we go again: this setting is needed to enable people to work BOTH
with short tag templates AND in context when short tags can not be turned
on by system configuration (by technical, administrative or whatever
reason). We want to make it work WITHOUT requiring to change system
configuration, exactly for the reason that it would work in ANY system
configuration and WOULD NOT require any administrative work.
I see your point... but wouldn't it be better not to need that? Johannes'
idea seemed good to me, always assuming it's do-able.
- Steph
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I see your point... but wouldn't it be better not to need that?
Johannes' idea seemed good to me, always assuming it's do-able.
Well, yes, it would indeed, but we have a lot of <?= templates now so
either we allow <?= on no-short-tags (if XML guys out there will be OK
with it I might be OK too, as IMO no valid XML would have <?=) or invent
some other syntax - in which case a) it probably would be worse than <?=
since you hardly can get shorter and "opening tag + =" is kind-of
de-facto standard for such things by now and b) it's take time to
educate people to use new syntax, especially that unlike <?= it won't
work on PHP < 5.3 so people would stay away from it for a couple of
years (heck, people still use PHP 4 out there! not talking about 5.0).
So we have this:
- Leave it as is and be in World of Configuration Pain (TM)
- Allow <?= independent of short tags (my +1, dunno about XML templates
guys) - Invent some <?bleh and watch nobody using it
- Accept runtime short tags
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi Stas,
- Leave it as is and be in World of Configuration Pain (TM)
- Allow <?= independent of short tags (my +1, dunno about XML templates
guys)
This is the way I understood Johannes' proposal - shoot me if I'm wrong here
Johannes.
But I don't have the means of testing to hand, so I'm willing/expecting to
be told why this is a bad idea by those that do.
- Steph
- Invent some <?bleh and watch nobody using it
- Accept runtime short tags
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Oh and ps
- Leave it as is and be in World of Configuration Pain (TM)
- Allow <?= independent of short tags (my +1, dunno about XML templates
guys)This is the way I understood Johannes' proposal - shoot me if I'm wrong
here Johannes.But I don't have the means of testing to hand, so I'm willing/expecting to
be told why this is a bad idea by those that do.
and I also agree with Johannes' point that any change here should be in PHP
6, regardless.
- Steph
Stanislav Malyshev wrote:
I see your point... but wouldn't it be better not to need that?
Johannes' idea seemed good to me, always assuming it's do-able.Well, yes, it would indeed, but we have a lot of <?= templates now so
either we allow <?= on no-short-tags (if XML guys out there will be OK
with it I might be OK too, as IMO no valid XML would have <?=) or invent
some other syntax - in which case a) it probably would be worse than <?=
since you hardly can get shorter and "opening tag + =" is kind-of
de-facto standard for such things by now and b) it's take time to
educate people to use new syntax, especially that unlike <?= it won't
work on PHP < 5.3 so people would stay away from it for a couple of
years (heck, people still use PHP 4 out there! not talking about 5.0).So we have this:
- Leave it as is and be in World of Configuration Pain (TM)
- Allow <?= independent of short tags (my +1, dunno about XML templates
guys)
I'd be ok with that too. It's not a valid PI tag, as far as I know, but
I don't think that is a problem.
One interesting observation is that there was a slight BC break related
to short tags between PHP 4 and 5 that I hadn't noticed before.
<?= /* 123 */ ?>
Works in PHP4 but results in a syntax error in PHP 5.
-Rasmus
Hello Stanislav,
Friday, March 21, 2008, 10:19:19 PM, you wrote:
http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.262&r2=1.263
guess who made that commit...
I wish I remembered what the rationale for that was, but of course I
don't. Anyway, in 7 years there might be a bit of a change in how people
use PHP, and that of course doesn't support the point of short tags
being evil in general.
But maybe the change is that now it is considered evil by an even larger
amount of people.
Best regards,
Marcus
But maybe the change is that now it is considered evil by an even larger
amount of people.
So far I saw four. I do not double I can find 5 people that like
templates with short tags. But anyway it doesn't matter much because
short tags are in PHP 5 and not going anywhere. So the question is do
you make user's life harder because they disagree with you - or do you
make them easier to use PHP even when they use it not the same way as
you do? I think the second way is better.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
But maybe the change is that now it is considered evil by an even larger
amount of people.So far I saw four. I do not double I can find 5 people that like templates
with short tags.
I don't think I've ever said I don't like short tags. It's not the issue
here. The issue is that allowing to change it during runtime adds more
WTF to PHP. WTF factors are bad.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
Hi!
I don't think I've ever said I don't like short tags. It's not the issue
here. The issue is that allowing to change it during runtime adds more
WTF to PHP. WTF factors are bad.
OK, there were people saying short tags are mortal sin, devil's device
to lure pure souls into the hell and what not. Good that you don't :)
Speaking of the WTF, I don't really see any major WTF since:
- 99.9% of the code (except for parser XML templates) works with any
tags settings. One that wouldn't work will bail out immediately with
clearly recognized error message, so the problem would be easy to locate
and fix. - For any code messing with this value - and this code should be only
one place in whole application, the template engine - it is very easy to
restore it afterwards, and any programmer smart enough to write in PHP
would know to do that. - There are a bunch of runtime settings that some code can influence
other code with - most prominent being include path - and we had very
little problem with them being INI_ALL. - This change actually does not remove any existing scenarios and adds
one previously impossible - having short tag templates in the context
where enabling short tags for whole application is not desired.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
I don't think I've ever said I don't like short tags. It's not the issue
here. The issue is that allowing to change it during runtime adds more
WTF to PHP. WTF factors are bad.OK, there were people saying short tags are mortal sin, devil's device
to lure pure souls into the hell and what not. Good that you don't :)
Speaking of the WTF, I don't really see any major WTF since:
- 99.9% of the code (except for parser XML templates) works with any
tags settings. One that wouldn't work will bail out immediately with
clearly recognized error message, so the problem would be easy to locate
and fix.- For any code messing with this value - and this code should be only
one place in whole application, the template engine - it is very easy to
restore it afterwards, and any programmer smart enough to write in PHP
would know to do that.- There are a bunch of runtime settings that some code can influence
other code with - most prominent being include path - and we had very
little problem with them being INI_ALL.- This change actually does not remove any existing scenarios and adds
one previously impossible - having short tag templates in the context
where enabling short tags for whole application is not desired.
You do know that having short tags enabled will result in a parse
error in the following situation, right?:
foo.php
<?xml version="1.0">
<root>
<?php
foreach($array as $el => $val) {
printf('<%s>%s</%2$s>', $el, $val);
}
?>
</root>
I actually think that by now the most common way to do exactly this
is: echo '<?xml version="1.0">'; so being PHP_INI_ALL isn't the worst
idea ever - but I still think it'll just create more wtf then
necessary.
-Hannes
You do know that having short tags enabled will result in a parse
error in the following situation, right?:
Yes, I do know. In fact, I mentioned this knowledge in virtually every
email on the subject. Your point being?
idea ever - but I still think it'll just create more wtf then
necessary.
I will repeat it as many times as necessary:
- This situation can happen only if you have written very buggy
template code - there exists no such code right now and one has to be
rather sloppy to create such code. Use quality libraries :) At least as
template engine. - This situation is very rare use case for PHP anyway, since most
templates in PHP aren't XML. - This situation is very easy to prevent and very easy to recognize if
not prevented.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I will repeat it as many times as necessary:
- This situation can happen only if you have written very buggy
template code - there exists no such code right now and one has to be
rather sloppy to create such code. Use quality libraries :) At least as
template engine.
So the template is responsible for ini_set("short_open_tags", false) ?
If I include your high quality template library it will do ini_set(..
true) at the top, before parsing the templates, and then
ini_set(..false) at the bottom?
- This situation is very rare use case for PHP anyway, since most
templates in PHP aren't XML.
So what if most templates in PHP aren't XML files? What does that have
to do with anything?
If I include your template library and then decied to bump out RSS..
your short tags enabling infected my php generated xml file with a
parse error - even if I explicitly had put short_open_tags = off in my
.htaccess
- This situation is very easy to prevent and very easy to recognize if
not prevented.
No? Random syntax errors on <?xml - even if I have short_open_tags
disabled in my php.ini, virtualhost setting and .htaccess...
-Hannes
On Wed, Mar 26, 2008 at 9:39 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
I will repeat it as many times as necessary:
- This situation can happen only if you have written very buggy
template code - there exists no such code right now and one has to be
rather sloppy to create such code. Use quality libraries :) At least as
template engine.So the template is responsible for ini_set("short_open_tags", false) ?
If I include your high quality template library it will do ini_set(..
true) at the top, before parsing the templates, and then
ini_set(..false) at the bottom?
Ouh. No. Wait. They can't do that since I may have had short_open_tags
already enabled...
They'll have to $old = ini_set("short_open_tags", false); include
"templates"; ini_set("short_open_tags", $old);
-Hannes
Hello Hannes,
Wednesday, March 26, 2008, 9:41:31 PM, you wrote:
On Wed, Mar 26, 2008 at 9:39 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:I will repeat it as many times as necessary:
- This situation can happen only if you have written very buggy
template code - there exists no such code right now and one has to be
rather sloppy to create such code. Use quality libraries :) At least as
template engine.So the template is responsible for ini_set("short_open_tags", false) ?
If I include your high quality template library it will do ini_set(..
true) at the top, before parsing the templates, and then
ini_set(..false) at the bottom?
Ouh. No. Wait. They can't do that since I may have had short_open_tags
already enabled...
They'll have to $old = ini_set("short_open_tags", false); include
"templates"; ini_set("short_open_tags", $old);
There you go. It's not that easy. And that's the whole point here. We are
making it yet again way more complex. I thought we wanted to reduce the
amount of INI settings. Now we even open them?
Marcus
Hi!
I don't think I've ever said I don't like short tags. It's not the
issue here. The issue is that allowing to change it during runtime
adds more WTF to PHP. WTF factors are bad.
- For any code messing with this value - and this code should be
only one place in whole application, the template engine - it is
very easy to restore it afterwards, and any programmer smart enough
to write in PHP would know to do that.
do note that we have increasingly large numbers of way to jump out of
the scope (exceptions, recoverable errors). this obviously makes these
kinds of cleanups potentially easier to forget.
regards,
Lukas
Hi!
do note that we have increasingly large numbers of way to jump out of
the scope (exceptions, recoverable errors). this obviously makes these
kinds of cleanups potentially easier to forget.
You'd need to catch and process exceptions anyway, and recoverable
errors, as far as I understand, are not meant as jumping out of scope
(you can run the handler, but the you're back to where the error was,
right?).
However, exceptions are a good point - actually, the first good
objection to this thing. Need to think if this can be solved easily.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com