Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51107
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=Dp8vmAohv2UcFGTtLoRYgTNuMRlZ3aFb0GzsZbkazlbtU86LIq4gP5QQeTQ6fU2lqH
         OdF5n3EPdkeEsAr1zYO44FJpcV2KTVga/Use1Zj9SbHlRpHnq+payBQ1TBCqGBqSGlut
         3ATFRe+oJuPgeY6YiWVI8T2dwYVMRW0El2ER8=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=0H-65nyuNHd7bAb3y+_2ueW8ZqwEyWhaRYuXE@mail.gmail.com>
References: <AANLkTim-Ekq=UeY-TXtryrbjR9=JpJOuPceTUaP5y0Rp@mail.gmail.com>
	<AANLkTikWg_oQRF8yR9xMjjFMcojmGuzdXAjborhpqrk8@mail.gmail.com>
	<F3.1D.35939.1513E0D4@pb1.pair.com>
	<AANLkTik6UFNcBZU2n5coq24m-DznZkG1p16CfRwPYRf4@mail.gmail.com>
	<AANLkTin9oWif8cVvJV+AcwPpKYGucYOwz2XTOiGDfkiQ@mail.gmail.com>
	<AANLkTimoajnug41On91jB6p=nkyF_rmAtYmS3mUUy1N9@mail.gmail.com>
	<AANLkTi=4Mkot7HAt163QSYhckzAsEf6v6ybEU0APN0Pg@mail.gmail.com>
	<AANLkTi=0H-65nyuNHd7bAb3y+_2ueW8ZqwEyWhaRYuXE@mail.gmail.com>
Date: Tue, 21 Dec 2010 11:43:52 -0500
Message-ID: <AANLkTi=pxMGXbAZdd73DrEQHOA0vCd0VbMVFHOxrGzRB@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016365ee0e07cac740497ee57da
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: dmgx.michael@gmail.com (Michael Morris)

--0016365ee0e07cac740497ee57da
Content-Type: text/plain; charset=ISO-8859-1

That would make for an easier situation.  If we don't worry about legacy for
a moment that would give us this cleaner bitfield.

Bit
0 -- Standard tags toggle
1 -- Short tags toggle
2 -- ASP tags toggle
3 -- Script tags toggle
4 -- Short echo toggle.

For backwards compat ship with bits 0 and 3 set on. The existing short tags
mode is bits 1 and 4 on. If all the bits are turned off then we have the
PHP_TAGS_NONE setting. In that mode the engine must assume the whole file is
going to be PHP code since there are no tags to look for.

I honestly like this best of what has been suggested so far, BUT the need to
adjust settings after upgrade is a major concern.  Admins who never enabled
asp or short tags to begin with wouldn't notice the settings going away, and
those that have I would expect to be savvy enough to transfer the setting
change themselves.

Another possbility is to have PHP set tag_style according to whether it sees
short_open_tags and asp_tags in the ini file.  If either of them are on, and
tag_style wasn't explicitly set, then php will set tag style to the values
it must have to mimic the intent of the setting. If tag_style is explicitly
set then it wins out - but a deprecated notice gets thrown to alert the user
that they have both tag_style set and short_open_tags and/or asp_tags set
on.

If an htaccess or httpd.conf directive explicitly calls for short_tags or
asp_tags after tag_style was explicitly set a warning of some sort is thrown
informing the user that they must switch that declaration to one compatible
with the php.ini file.  Ditto for sets occurring at runtime with one
exception - if the user specifies tag style from the include or require
statement itself this shouldn't raise any error.

(That there's no comment on the adding of the second param to those function
as of yet concerns me a little - it is somewhat key to the proposal.)

Anyway, the trickiest part of this is balancing the past with the future.

--0016365ee0e07cac740497ee57da--