Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51653
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 81246 invoked from network); 10 Mar 2011 14:52:15 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 10 Mar 2011 14:52:15 -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:41323] helo=mail-wy0-f170.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id E3/A0-11443-E95E87D4 for <internals@lists.php.net>; Thu, 10 Mar 2011 09:52:14 -0500
Received: by wyb34 with SMTP id 34so1459174wyb.29
        for <internals@lists.php.net>; Thu, 10 Mar 2011 06:52:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:date:message-id:subject:from:to
         :content-type;
        bh=4XG4LIsQ86kNN/+afTTsaxwyItOcPILN0sY8Av1+VcU=;
        b=p1jaID4lKrW1MlCN9Ba3QRwVgSxJ+NhC6PCiIBek8g05t+q90/yvILyOq6svi6BLnu
         F9C3XwNiV5UatTANb9r1wxNU130Ijhl0s8Q0uCM5bDc4s7YH/Iu1hmboBa/b/lQAam/A
         fp2v0wJLyiWu8SBryvkmXs59Xnb4vO5pwBjBc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=r485yQ0UgEXQ2APbdOUsKLOaXzpr/1i04/dkI83aHaVtgJe7kL+RAYHQh/tMIlfmso
         Tb1FneLHUOlTdc2P8XxtG2CV6jK0W5f0dnbVFQdZysZdxEXbLzFzINNeB43bi1ei40/J
         /7wAvvfN6A0ZK/WCBnxhNToZZHNMpM+YR/1gw=
MIME-Version: 1.0
Received: by 10.216.19.133 with SMTP id n5mr5806768wen.83.1299768731173; Thu,
 10 Mar 2011 06:52:11 -0800 (PST)
Received: by 10.216.86.14 with HTTP; Thu, 10 Mar 2011 06:52:11 -0800 (PST)
Date: Thu, 10 Mar 2011 09:52:11 -0500
Message-ID: <AANLkTi=6SQb0i0hHaMjMNCBEgj_zQ3W=nzgs+y_kO0qp@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016368e3059830230049e21fd72
Subject: [PHP-DEV] RFC Dynamic Tag Styles, and No Tags
From: dmgx.michael@gmail.com (Michael Morris)

--0016368e3059830230049e21fd72
Content-Type: text/plain; charset=ISO-8859-1

About two months ago I placed an RFC to the list on this and we had a pretty
good conversation on it.  I've started the process of brushing my C skills
up to the this task.  Before I begin with this I'd like to review this one
more time - I made some changes from the original proposal. Since the
original thread is now 2 months gone I've chosen to start anew.  So here
goes...


This patch makes it possible for the programmer to more directly configure
which tags are used to delimit PHP code in PHP files. It will also permit
the programmer to choose to work without tags at all and treat the whole
file as a php block. I'm hoping to pick up some speed in this instance since
the byte code compiler won't need to worry with mode switching in that case.

The change involves one new ini directive - tag_style and four new constants
- PHP_TAGS_STANDARD, PHP_TAGS_SHORT, PHP_TAGS_ASP, PHP_TAGS_NONE.

The value of the directive is this bitfield.

Bit  Tags
0    <?php
1    <?
2    <?=
3    ?>
4    <script type="php">
5    </script>
6    <%
7    <%=
8    %>
9    <?php=

The constants will be defined to hold the combinations that should see the
most use.

Value Constant
0     PHP_TAGS_NONE
9     PHP_TAGS_STANDARD
15    PHP_TAGS_SHORT
196   PHP_TAGS_ASP

The new ini directive -- tag_style -- holds this value. If unset PHP false
back to current behavior for backwards compatibility. If set in conjunction
with the two existing tag control settings ( short_open_tag and asp_tags )
then its value will be added to the respective constants for those settings
on start - possibly with a core notice or warning being emitted (This
behavior is for backwards compatibility, but not encouraged in practice). If
this patch is accepted the other two ini directives dealing with tags would
be deprecated for future removal as they are redundant to this system.

Programmers can use ini_set() to change the parsing method - but this will
only affect future includes.  Includes that have already compiled will
obviously not be affected.  Hence ini_set('tag_style', PHP_TAGS_OPEN) will
let you turn on short tags for including any templates you created that use
them for legibility, and then you could turn them back off to work with xml
files.

The four inclusion statements - require, require_once, include, include_once
- will be modified to take an integer as a second argument, and that integer
will be the bitfield of the tag style.  If omitted the statement will use
the current setting.

Setting the tag_style to 0 is PHP_TAGS_NONE, which has the special property
that PHP will presume the whole file is PHP code, as if it was wrapped with
open and closing tags.

Any invalid setting (open tags with no closure) tag will be ignored and PHP
will revert to standard tags mode. A warning (notice, error?) will be
omitted when this occurs.

The main benefit of this system is it solves the short tags / xml tags
dilemna. Programmers will be able to set tags as they desire for their
projects. Portable projects such as Joomla need only make sure their first
file conforms to standard tags since they may then switch it as needed,
allowing them to use short tags for the first time.

A second benefit is files can be segregated to the tags they need.  No
longer will class files which never should be outputting data need to have
tags.  Aside from relieving one of PHP's idiosyncratic eyesores, framework
designers will be able to enforce tag formats for different sections of the
framework. For example, in my own system .phtml files are templates and use
short tags.  No other files in the framework output anything, so no_tags
could be set.

I think this is a suitable working spec to build from for a first draft. I
may need to modify it once coding begins. Advice appreciated on
how feasible this approach will be from those familiar with the code that
will have to change to accommodate this. All other comments on this welcome
as well.

--0016368e3059830230049e21fd72--