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

On 21 December 2010 16:00, Michael Morris <dmgx.michael@gmail.com> wrote: > 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