Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36307
Return-Path: <rasmus@lerdorf.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 15389 invoked from network); 22 Mar 2008 00:20:09 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 22 Mar 2008 00:20:09 -0000
Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
X-PHP-List-Original-Sender: rasmus@lerdorf.com
X-Host-Fingerprint: 204.11.219.139 mail.lerdorf.com  
Received: from [204.11.219.139] ([204.11.219.139:60975] helo=mail.lerdorf.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 49/B7-26785-9B054E74 for <internals@lists.php.net>; Fri, 21 Mar 2008 19:20:09 -0500
Received: from [192.168.200.148] (c-24-6-219-206.hsd1.ca.comcast.net [24.6.219.206])
	(authenticated bits=0)
	by mail.lerdorf.com (8.14.2/8.14.2/Debian-3) with ESMTP id m2M0K2cO007346;
	Fri, 21 Mar 2008 17:20:03 -0700
Message-ID: <47E450B1.9040604@lerdorf.com>
Date: Fri, 21 Mar 2008 17:20:01 -0700
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Elizabeth M Smith <auroraeosrose@gmail.com>
CC:  internals@lists.php.net
References: <47E3F714.60302@zend.com>  <883216194.20080321193140@marcus-boerger.de>  <47E40848.1060103@zend.com> <47E40C3F.8040601@sci.fi>  <47E40E6E.5030103@zend.com> <47E410C6.80605@sci.fi>  <47E4146A.8010409@zend.com> <fe05d1540803211313j22578632rfabe22f53592eb6d@mail.gmail.com> <47E41765.4080007@zend.com> <111239762.20080321212310@marcus-boerger.de> <47E41C9F.4040105@zend.com> <935033306.20080321223836@marcus-boerger.de> <68.F2.26785.55E24E74@pb1.pair.com>
In-Reply-To: <68.F2.26785.55E24E74@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.92.1/6321/Fri Mar 21 15:55:45 2008 on colo.lerdorf.com
X-Virus-Status: Clean
Subject: Re: [PHP-DEV] short_open_tag
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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