On Mon, Dec 20, 2010 at 7:02 AM, Michael Morris <dmgx.mich...@gmail.com> wrote: > 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.
Zero is zero, there can be no "whatever tags are specified by the higher bits of this setting." because that would be other than zero. > 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 < > weierophin...@php.net> wrote: > >> 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 >> >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
