Re: RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.)

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 > >