RFC Dynamic Tag Styles, and No Tags View as Markdown

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.