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.
On Thu, Dec 9, 2010 at 3:53 PM, Michael Morris dmgx.michael@gmail.comwrote:
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.
This also would help prevent accidentally putting whitespace before the
<?php that
can cause problems with header()