# RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.) - Thread: https://externals.io/message/50987 - Original archive: https://news-web.php.net/php.internals/50987 - Started by Michael Morris on 2010-12-10T01:25:02+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #50987 — Michael Morris — 2010-12-10T01:25:02+00:00 URL: https://externals.io/message/50987#50987 Forgive me - it's been a *long* time since I've used a listserv, and I'm still getting the hang of getting the message tags exat. Reposting for those who may have missed this because I got the exact format of the tags wrong the first time around. On Thu, Dec 9, 2010 at 3:53 PM, Michael Morris wrote: > Been pointed this way by some folks that this is the place to set > suggestions on changes to the functions or language. I have two at the > moment, and that is to the including functions (include, require, > include_once, require_once). They need to be considered separately as they > address two different problems. > > Tag Selection at include. > First is the problem of short tags and they aren't being widely used > because of the problems they cause for XML files. > > Why not allow the tag type to be chosen at file include? This should bypass > the objections seen in http://wiki.php.net/rfc/shortags > > The parameter would be set by a constant. > > Val Constant Effect > 0 PHP_TAGS_INI Use the ini setting. Default. > 1 PHP_TAGS_STANDARD Use standard PHP tags. > 2 PHP_TAGS_SHORT Use PHP short tags. > 3 PHP_TAGS_NONE No tags allowed in file, parse as PHP. > 4 PHP_TAGS_SCRIPT Script tags > 5 PHP_TAGS_ASP ASP style tags <% %> > > PHP_TAGS_NONE is suggested as a possible bonus mode this approach allows > that wouldn't be feasible otherwise. In this mode the engine treats the > whole file as PHP and doesn't allow mode switching. This might allow the > engine to parse the file faster. Importantly it would allow framework > designers to enforce that certain files not have HTML in them - such as a > database class, or a custom child class. Admittedly it doesn't stop > echo'ing the html, but it drives home the point to all but the densest that > perhaps this isn't the place to be printing/echoing. It's use would > encounter the problem of current IDE tools assuming that a PHP file will > always have a starting > The tag method selected affects the file being included only, so tag modes > that are undesirable in some circumstances - short tags - can be segregated > from those circumstance. > > > Namespace Defined At Include. > This addresses a separate problem from the above, but involves the same > functions - though it might be better to have another rather than a new > parameter on the include statements. The problem is that files always > include to the global namespace, then need to defined their namespace. This > behavior is undesirable with PHP template files and putting a namespace tag > at their start is clumsy at best. Two solutions are proposed - they aren't > exclusive to each other. > > Solution 1. Allow Namespace to be declared as file is included. > Hence > > include('file.php', __NAMESPACE__); > > Would include the code in file.php into the current namespace. If file.php > declares a namespace, then that namespace becomes a sub namespace. > > Solution 2. New function to set target namespace. > > setIncludeNamespace( __NAMESPACE__ ); // will set current namespace as the > default files include into. > > Both could be adopted. > > Ok, that's all. --- ## #51069 — Michael Morris — 2010-12-17T18:09:18+00:00 URL: https://externals.io/message/50987#51069 · In reply to: #50987 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 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 alongside the and tags. 4 PHP_TAGS_SCRIPT Script tags 5 PHP_TAGS_ASP ASP style tags <% %> 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. --- ## #51071 — Stanley Sufficool — 2010-12-18T04:27:45+00:00 URL: https://externals.io/message/50987#51071 · In reply to: #51069 I would go with a maskable enumeration for multiple options support: Val Constant 0 PHP_TAGS_NONE 1 PHP_TAGS_LEGACY 2 PHP_TAGS_STANDARD 4 PHP_TAGS_SHORT 8 PHP_TAGS_SCRIPT 16 PHP_TAGS_ASP So that if I want to use mixed tags ( 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 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 >                         alongside the and >                         tags. > 4    PHP_TAGS_SCRIPT    Script tags > 5    PHP_TAGS_ASP       ASP style tags <% %> > > 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. --- ## #51091 — Matthew Weier O'Phinney — 2010-12-19T16:22:41+00:00 URL: https://externals.io/message/50987#51091 · In reply to: #51069 > --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 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 > alongside the and > tags. > 4 PHP_TAGS_SCRIPT Script tags > 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 " 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 --- ## #51095 — Michael Morris — 2010-12-20T15:02:08+00:00 URL: https://externals.io/message/50987#51095 · In reply to: #51091 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 ( ) 4 - short tags () 8 - asp ( <% %> ) 16 - Shorthand echo ( ) 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: > > > […] > name: > > […] > > 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 " allow utilization of " > 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. > > > […] > an > > […] > once > > […] > made, > > […] > that > > […] > > > -- > 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 --- ## #51100 — Stanley Sufficool — 2010-12-20T21:52:07+00:00 URL: https://externals.io/message/50987#51100 · In reply to: #51095 > 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 ( ) > 4 - short tags () > 8 - asp ( <% %> ) > 16 - Shorthand echo ( 32 - Script tags ( ) > > 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: > > > […] --- ## #51105 — Michael Morris — 2010-12-21T16:00:17+00:00 URL: https://externals.io/message/50987#51105 · In reply to: #51100 Uhm, If bit 0 is set to 0, and all the higher bits are also set to 0, then the total value of the field is 0. Under this scheme bit 0 is the legacy mode bit. Turn it off and PHP will parse tags according to historical behavior and respects the asp_tags and short_open_tags flag. Turn it on and those behaviors go away. The weird part about this particular bit is you have to turn it on in order to turn something off. I don't like doing that, but I don't see another way to keep backwards compatibility since PHP should act as it currently does if this setting isn't set or is left at '0'. On Mon, Dec 20, 2010 at 4:52 PM, Stanley Sufficool wrote: > On Mon, Dec 20, 2010 at 7:02 AM, Michael Morris > wrote: > > […] > compatibility > > […] > setting. > > […] > settings - > > […] > > 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. > > > […] > opening > > […] > getting > > […] > recommendation > > […] > to > > […] > parsed. > > […] > the > > […] > compatibility > > […] > drop > > […] --- ## #51106 — Richard Quadling — 2010-12-21T16:15:12+00:00 URL: https://externals.io/message/50987#51106 · In reply to: #51105 > Uhm, If bit 0 is set to 0, and all the higher bits are also set to 0, then > the total value of the field is 0. > > Under this scheme bit 0 is the legacy mode bit.  Turn it off and PHP will > parse tags according to historical behavior and respects the asp_tags and > short_open_tags flag.  Turn it on and those behaviors go away.  The weird > part about this particular bit is you have to turn it on in order to turn > something off. I don't like doing that, but I don't see another way to keep > backwards compatibility since PHP should act as it currently does if this > setting isn't set or is left at '0'. Would it not be feasible to drop asp_tags and short_open_tags, replacing them with the new entry and have the default value of the entry set so that it is corresponds to the default values of the asp_tags and short_open_tags? As the default (based upon php.ini-development and php.ini-production) is to set asp_tags and short_open_tags to off, it would seem that a new ini entry, replacing the older tags, doesn't need to worry about the value in the recommended/default position. Alternatively, could the default value (for when there isn't one defined in a current ini file) simply be based upon whatever is set for asp_tags and short_open_tags? Essentially, subsuming the older settings into the new one and allowing a sysadmin/developer to set the value if they want to. I don't think it would be necessary to support the old style settings if the change was done at a major version, though asp_tags and short_open_tags could be marked as deprecated in the next minor release. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY --- ## #51107 — Michael Morris — 2010-12-21T16:43:52+00:00 URL: https://externals.io/message/50987#51107 That would make for an easier situation. If we don't worry about legacy for a moment that would give us this cleaner bitfield. Bit 0 -- Standard tags toggle 1 -- Short tags toggle 2 -- ASP tags toggle 3 -- Script tags toggle 4 -- Short echo toggle. For backwards compat ship with bits 0 and 3 set on. The existing short tags mode is bits 1 and 4 on. If all the bits are turned off then we have the PHP_TAGS_NONE setting. In that mode the engine must assume the whole file is going to be PHP code since there are no tags to look for. I honestly like this best of what has been suggested so far, BUT the need to adjust settings after upgrade is a major concern. Admins who never enabled asp or short tags to begin with wouldn't notice the settings going away, and those that have I would expect to be savvy enough to transfer the setting change themselves. Another possbility is to have PHP set tag_style according to whether it sees short_open_tags and asp_tags in the ini file. If either of them are on, and tag_style wasn't explicitly set, then php will set tag style to the values it must have to mimic the intent of the setting. If tag_style is explicitly set then it wins out - but a deprecated notice gets thrown to alert the user that they have both tag_style set and short_open_tags and/or asp_tags set on. If an htaccess or httpd.conf directive explicitly calls for short_tags or asp_tags after tag_style was explicitly set a warning of some sort is thrown informing the user that they must switch that declaration to one compatible with the php.ini file. Ditto for sets occurring at runtime with one exception - if the user specifies tag style from the include or require statement itself this shouldn't raise any error. (That there's no comment on the adding of the second param to those function as of yet concerns me a little - it is somewhat key to the proposal.) Anyway, the trickiest part of this is balancing the past with the future. --- ## #51254 — Michael Morris — 2011-01-11T22:03:18+00:00 URL: https://externals.io/message/50987#51254 · In reply to: #51107 Bumping this after about a 3 week lull. How would I go about adding this to the wiki?? On Tue, Dec 21, 2010 at 11:43 AM, Michael Morris wrote: > That would make for an easier situation. If we don't worry about legacy > for a moment that would give us this cleaner bitfield. > > Bit > 0 -- Standard tags toggle > 1 -- Short tags toggle > 2 -- ASP tags toggle > 3 -- Script tags toggle > 4 -- Short echo toggle. > > For backwards compat ship with bits 0 and 3 set on. The existing short tags > mode is bits 1 and 4 on. If all the bits are turned off then we have the > PHP_TAGS_NONE setting. In that mode the engine must assume the whole file is > going to be PHP code since there are no tags to look for. > > I honestly like this best of what has been suggested so far, BUT the need > to adjust settings after upgrade is a major concern. Admins who never > enabled asp or short tags to begin with wouldn't notice the settings going > away, and those that have I would expect to be savvy enough to transfer the > setting change themselves. > > Another possbility is to have PHP set tag_style according to whether it > sees short_open_tags and asp_tags in the ini file. If either of them are > on, and tag_style wasn't explicitly set, then php will set tag style to the > values it must have to mimic the intent of the setting. If tag_style is > explicitly set then it wins out - but a deprecated notice gets thrown to > alert the user that they have both tag_style set and short_open_tags and/or > asp_tags set on. > > If an htaccess or httpd.conf directive explicitly calls for short_tags or > asp_tags after tag_style was explicitly set a warning of some sort is thrown > informing the user that they must switch that declaration to one compatible > with the php.ini file. Ditto for sets occurring at runtime with one > exception - if the user specifies tag style from the include or require > statement itself this shouldn't raise any error. > > (That there's no comment on the adding of the second param to those > function as of yet concerns me a little - it is somewhat key to the > proposal.) > > Anyway, the trickiest part of this is balancing the past with the future. --- ## #51255 — Christopher Jones — 2011-01-12T00:20:03+00:00 URL: https://externals.io/message/50987#51255 · In reply to: #51254 > Bumping this after about a 3 week lull. How would I go about adding this to > the wiki?? The normal way: get a wiki account and create an RFC. I believe this is the the place to request wiki access: http://wiki.php.net/start?do=register I didn't see much buy-in on the list, so you might want to work on a C patch and testcases before spending time on polishing the RFC. Chris -- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/