Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51095
Return-Path: <dmgx.michael@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 42718 invoked from network); 20 Dec 2010 15:02:17 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 20 Dec 2010 15:02:17 -0000
Authentication-Results: pb1.pair.com smtp.mail=dmgx.michael@gmail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=dmgx.michael@gmail.com; sender-id=pass; domainkeys=bad
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
DomainKey-Status: bad
X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01
X-PHP-List-Original-Sender: dmgx.michael@gmail.com
X-Host-Fingerprint: 74.125.82.170 mail-wy0-f170.google.com  
Received: from [74.125.82.170] ([74.125.82.170:51704] helo=mail-wy0-f170.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 12/65-11788-2FF6F0D4 for <internals@lists.php.net>; Mon, 20 Dec 2010 10:02:12 -0500
Received: by wyb39 with SMTP id 39so2848665wyb.29
        for <internals@lists.php.net>; Mon, 20 Dec 2010 07:02:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:in-reply-to
         :references:date:message-id:subject:from:to:content-type;
        bh=sI0gQlNhJCZUe+YW68l0C3rJ/BPUnaUDh7LozB67mEQ=;
        b=PbdRphyMdVv0FNRsy0DJMFrzN7MSpPyg97XZtA/1JdDHlCT/nTV0NnfN0dz7FhBJr4
         nXa9D64J1457QQsuGa3JF/0Ys3R3UjiXYphp+3FQNldg82apvfbJ/IKn0EC6JvM+ie2H
         BpM1hI1ktP33VAGqeeIuqRrZq2N9k00ySH60U=
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=ERivNztJ0piz+jkaLawqEL/r6IZKfe9C2zg7neV70Ty17/ymYgzELHZnZR+/pJSDX/
         a0rdqVkZ243TEwfsOiQjS7KPtyDb35+03YPTlS0FKxMu1I1li1wkOgkIhkVXTnyKfx/8
         pBWBYdd85eWbalqgddaHW5jJgZOye1O98dpXE=
MIME-Version: 1.0
Received: by 10.216.11.8 with SMTP id 8mr7486364wew.0.1292857328105; Mon, 20
 Dec 2010 07:02:08 -0800 (PST)
Received: by 10.216.45.148 with HTTP; Mon, 20 Dec 2010 07:02:08 -0800 (PST)
In-Reply-To: <F3.1D.35939.1513E0D4@pb1.pair.com>
References: <AANLkTim-Ekq=UeY-TXtryrbjR9=JpJOuPceTUaP5y0Rp@mail.gmail.com>
	<AANLkTikWg_oQRF8yR9xMjjFMcojmGuzdXAjborhpqrk8@mail.gmail.com>
	<F3.1D.35939.1513E0D4@pb1.pair.com>
Date: Mon, 20 Dec 2010 10:02:08 -0500
Message-ID: <AANLkTik6UFNcBZU2n5coq24m-DznZkG1p16CfRwPYRf4@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016364d23dbc9784e0497d8cde9
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)

--0016364d23dbc9784e0497d8cde9
Content-Type: text/plain; charset=ISO-8859-1

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.  Backwards compatibility
needs to have the 0 setting both for the function calls and the ini setting.
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 settings -
and whatever tags are specified by the higher bits of this setting.
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=, <?=, <%= )
32 - Script tags (<script type="php"> </script> )

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

--0016364d23dbc9784e0497d8cde9--