Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.) [RSS Feed]

#1 Dec. 17, 2010 18:10:28

Michael M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

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


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

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.

Offline

#2 Dec. 18, 2010 04:28:39

Stanley S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

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


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 (<?php and <?) then I can set

tag_style = PHP_TAGS_SHORT | PHP_TAGS_STANDARD
or
tag style = 6

IMHO, I think is more flexible and understandable.

On Fri, Dec 17, 2010 at 10:09 AM, Michael Morris <dmgx.mich***@*mail.com> wrote:
> 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 <% %>
>
> 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.
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 Dec. 19, 2010 16:24:06

Matthew W.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

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


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

Offline

#4 Dec. 20, 2010 15:03:13

Michael M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] 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 <
weierophin***@*hp.net> wrote:

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

Offline

#5 Dec. 20, 2010 21:53:10

Stanley S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

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


On Mon, Dec 20, 2010 at 7:02 AM, Michael Morris <dmgx.mich***@*mail.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***@*hp.net> wrote:
>
>> On 2010-12-17, Michael Morris <dmgx.mich***@*mail.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***@*end.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

Offline

#6 Dec. 21, 2010 16:01:48

Michael M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

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


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 <ssuffic***@*mail.com>wrote:

> On Mon, Dec 20, 2010 at 7:02 AM, Michael Morris <dmgx.mich***@*mail.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***@*hp.net> wrote:
> >
> >> On 2010-12-17, Michael Morris <dmgx.mich***@*mail.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***@*end.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> >>
> >>
> >
>

Offline

#7 Dec. 21, 2010 16:16:20

Richard Q.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] 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.mich***@*mail.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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#8 Dec. 21, 2010 16:45:23

Michael M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

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


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.

Offline

#9 Jan. 11, 2011 22:04:11

Michael M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

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


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 <dmgx.mich***@*mail.com>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.
>
>
>

Offline

#10 Jan. 12, 2011 00:20:50

Christopher J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

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


On 01/11/2011 02:03 PM, Michael Morris wrote: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=registerI 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.jo***@*racle.com
Tel: +1 650 506 8630
Blog:http://blogs.oracle.com/opal/--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.) [RSS Feed]

Board footer

Moderator control

Enjoy the 19th of October
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support