Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51100
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.182 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
         :cc:content-type:content-transfer-encoding;
        b=J8GaC4FzgvA9ZfWvQmAshLLU1I6FaCDDIr0q1aN9G9jQ3L80ehP5UCYPs3cHwV1qIs
         IPslSnjMMXESNqX7dUdRNbtdwL5uDmTNrnl8fBZ2dFN8wvUjkoIVeZXDpmmg6ZsKWEnb
         4WW49Vpju4wqkHQ9gnJykbkM/axPGi+P6cCMk=
MIME-Version: 1.0
In-Reply-To: <AANLkTik6UFNcBZU2n5coq24m-DznZkG1p16CfRwPYRf4@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>
Date: Mon, 20 Dec 2010 13:52:07 -0800
Message-ID: <AANLkTin9oWif8cVvJV+AcwPpKYGucYOwz2XTOiGDfkiQ@mail.gmail.com>
To: Michael Morris <dmgx.michael@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: ssufficool@gmail.com (Stanley Sufficool)

On Mon, Dec 20, 2010 at 7:02 AM, Michael Morris <dmgx.michael@gmail.com> wr=
ote:
> I'm not opposed to using a bitfield, but it's going to be tricky to do
> because there are two settings that want to be 0. =A0Backwards compatibil=
ity
> needs to have the 0 setting both for the function calls and the ini setti=
ng.
> However, the no tags mode also wants to be a 0 logically.
>
> The best I can come up with to mitigate this problem is this.
>
> Bit 1 would toggle these two modes.
> 0 - Backwards compatibility - use the short_open_tags and asp_tag setting=
s -
> and whatever tags are specified by the higher bits of this setting.

Zero is zero, there can be no "whatever tags are specified by the
higher bits of this setting." because that would be other than zero.

> 1 - No tags expect as specified in this setting.
>
> Then the other bits would be more simple on/off toggles.
> 2 - normal tags (<?php ?> )
> 4 - short tags (<? ?>)
> 8 - asp ( <% %> )
> 16 - Shorthand echo ( <?php=3D, <?=3D, <%=3D )
> 32 - Script tags (<script type=3D"php"> </script> )
>
> And so on. =A0Under this schema the PHP_SHORT_TAGS constant would be
> equivalent to 20 since that is what is expected by most people who use
> 'short tags'
>
>
> On Sun, Dec 19, 2010 at 11:22 AM, Matthew Weier O'Phinney <
> weierophinney@php.net> wrote:
>
>> On 2010-12-17, Michael Morris <dmgx.michael@gmail.com> wrote:
>> > --0016e6daa93aab9e2004979f11fa
>> > Content-Type: text/plain; charset=3DISO-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 =A0Constant =A0 =A0 =A0 =A0 =A0 Effect
>> > 0 =A0 =A0PHP_TAGS_LEGACY =A0 =A0Honor older ini tag settings such as a=
sp_tags
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or short_open_tag, =
in all ways behave in a
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a manner compliant =
with the expectations of
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0any scripts that ar=
e upgrading.
>> > 1 =A0 =A0PHP_TAGS_NONE =A0 =A0 =A0No tags will be permitted in the fil=
e.
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Interpreter expects=
 the whole file to be
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PHP.
>> > 2 =A0 =A0PHP_TAGS_STANDARD =A0Enable the classic <?php ?> tags we all =
know
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and love.
>> > 3 =A0 =A0PHP_TAGS_SHORT =A0 =A0 Use PHP short tags <? ?> and <?=3D ?>.=
 Unlike
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Legacy behavior wit=
h short_open_tag set to
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'on' this setting w=
ill NOT let you use
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<?php ?> alongside =
the <? ?> and <?=3D ?>
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tags.
>> > 4 =A0 =A0PHP_TAGS_SCRIPT =A0 =A0Script tags <script type=3D"php"></scr=
ipt>
>> > 5 =A0 =A0PHP_TAGS_ASP =A0 =A0 =A0 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 "<?=3D" without allowing support for "<?". So an option to
>> allow utilization of "<?=3D" 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 open=
ing
>> > tag at all. This would put a stop to the puzzlement of "Why am I getti=
ng
>> 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 recommendati=
on
>> > 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 parse=
d.
>> >
>> > 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 th=
e
>> > 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 compatibilit=
y
>> > issues or creating future problems. =A0As for the secondary suggestion=
 I
>> made,
>> > allowing namespaces to be specified in the include statement, I'll dro=
p
>> that
>> > from this recommendation to focus on the changes to tag style setting.
>> >
>> > --0016e6daa93aab9e2004979f11fa--
>>
>>
>> --
>> Matthew Weier O'Phinney
>> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| matthew@zend.com
>> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>