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