On 2010-12-17, Michael Morris <dmgx.mich...@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 | matt...@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
