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

14 years ago by Michael Morris — view source — reply

unread

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 dmgx.michael@gmail.comwrote:

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 <script type="php"></script>
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 <?php tag.

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.

14 years ago by Michael Morris — view source — reply

unread

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.

14 years ago by Stanley Sufficool — view source — reply

unread

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.

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.

14 years ago by Matthew Weier O'Phinney — view source — reply

unread

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

14 years ago by Michael Morris — view source — reply

unread

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:

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

14 years ago by Stanley Sufficool — view source — reply

unread

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 <
weierophinney@php.net> 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

14 years ago by Michael Morris — view source — reply

unread

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 ssufficool@gmail.comwrote:

On Mon, Dec 20, 2010 at 7:02 AM, Michael Morris dmgx.michael@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 <
weierophinney@php.net> 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

14 years ago by Richard Quadling — view source — reply

unread

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

14 years ago by Michael Morris — view source — reply

unread

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.

14 years ago by Michael Morris — view source — reply

unread

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.michael@gmail.comwrote:

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.

14 years ago by Christopher Jones — view source — reply

unread

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/