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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
