Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51091
Return-Path: <weierophinney@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 45753 invoked from network); 19 Dec 2010 16:22:41 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 19 Dec 2010 16:22:41 -0000
X-Host-Fingerprint: 65.19.76.48 unknown  
Date: Sun, 19 Dec 2010 11:22:41 -0500
Received: from [65.19.76.48] ([65.19.76.48:17367] helo=localhost.localdomain)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id F3/1D-35939-1513E0D4 for <internals@lists.php.net>; Sun, 19 Dec 2010 11:22:41 -0500
Message-ID: <F3.1D.35939.1513E0D4@pb1.pair.com>
To: internals@lists.php.net
References: <AANLkTim-Ekq=UeY-TXtryrbjR9=JpJOuPceTUaP5y0Rp@mail.gmail.com>
 <AANLkTikWg_oQRF8yR9xMjjFMcojmGuzdXAjborhpqrk8@mail.gmail.com>
User-Agent: slrn/pre1.0.0-18 (Linux)
X-Posted-By: 65.19.76.48
Subject: Re: [PHP-DEV] RFC: Selecting Namespaces and Tag styles at include
 time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include
 time.)
From: weierophinney@php.net (Matthew Weier O'Phinney)

On 2010-12-17, Michael Morris <dmgx.michael@gmail.com> wrote:
> --0016e6daa93aab9e2004979f11fa
> Content-Type: text/plain; charset=ISO-8859-1
>
> I've been giving some thought to the implication of my off the cuff
> addition of PHP_TAGS_NONE to the modes allowed and what should
> logically go with that. If tag style can be declared in a function, it
> should be possible set them in the configuration and at other places.
> Currently tag style is spread over multiple settings in the
> configuration - I know of two:
>
> asp_tags
> short_open_tag
>
> This is problematic moving forward so I hereby suggest nipping further
> proliferation in the bud and go to one configuration setting with this name:
>
> tag_style
>
> It's values, and their corresponding meaning:
>
> Val  Constant           Effect
> 0    PHP_TAGS_LEGACY    Honor older ini tag settings such as asp_tags
>                          or short_open_tag, in all ways behave in a
>                          a manner compliant with the expectations of
>                          any scripts that are upgrading.
> 1    PHP_TAGS_NONE      No tags will be permitted in the file.
>                          Interpreter expects the whole file to be
>                          PHP.
> 2    PHP_TAGS_STANDARD  Enable the classic <?php ?> tags we all know
>                          and love.
> 3    PHP_TAGS_SHORT     Use PHP short tags <? ?> and <?= ?>. Unlike
>                          Legacy behavior with short_open_tag set to
>                          'on' this setting will NOT let you use
>                          <?php ?> alongside the <? ?> and <?= ?>
>                          tags.
> 4    PHP_TAGS_SCRIPT    Script tags <script type="php"></script>
> 5    PHP_TAGS_ASP       ASP style tags <% %>

I like this level of configurability. It can still be improved, though.

One frequent request I've seen (and seen raised on-list as well) is
support for "<?=" without allowing support for "<?". So an option to
allow utilization of "<?=" within standard tags would be nice.

Second, make these potentially bitmask-able. I can see some folks
wanting the ability to do script tags and standard tags, but not short
tags and ASP tags. Having the setting allow bitmasks would solve that
problem.

Overall, though, this is a nice solution that should not present a BC
break.

> And so a script could have an .htaccess file with
>
> php_flag php_tags 1
>
> So the first file the webserver reads in doesn't have to have any opening
> tag at all. This would put a stop to the puzzlement of "Why am I getting an
> error when I call header()" which I see on programming boards at least once
> a week.
>
> The constants above can in turn be coupled to my original recommendation
> that include, include_once, require, and require_once each be allowed to
> have a second parameter. The default value of the second parmeter is
> whatever php_tags is set to at the time the include statement is parsed.
>
> Hence, unlike the current situation with short_open_tag and asp_tag,
> php_tags can be changed at runtime using ini_set. The only catch is the
> change only affects includes which occur after the setting change.
>
> I believe strongly that this improved recommendation improves the
> interoperability of tag styles without creating backwards compatibility
> issues or creating future problems.  As for the secondary suggestion I made,
> allowing namespaces to be specified in the include statement, I'll drop that
> from this recommendation to focus on the changes to tag style setting.
>
> --0016e6daa93aab9e2004979f11fa--


-- 
Matthew Weier O'Phinney
Project Lead            | matthew@zend.com
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc