Edit report at https://bugs.php.net/bug.php?id=61182&edit=1
ID: 61182
User updated by: tom at tomwardrop dot com
Reported by: tom at tomwardrop dot com
Summary: Assume Opening PHP Tag
Status: Open
Type: Feature/Change Request
Package: *Configuration Issues
PHP Version: 5.4.0RC8
Block user comment: N
Private report: N
New Comment:
It's not just about the extra characters, but like the end ?> tag (which
thankfully is optional), any white-space or otherwise non-printable characters
before the opening tag can cause "headers sent" issues. You could solve that
problem by implementing the ignore white-space rule I've already mentioned,
where any white-space before the opening tag is ignored.
The more I think about this and talk to the others, the more it becomes
apparent
that what I'm actually asking for, is a distinction to made between PHP
templates, and PHP scripts/applications. If PHP were to define these two
distinct concepts, then you could do more than just make the opening tag
optional. For example, you could have a template() or render() method to act as
an include() for php templates. Unlike include() however, this render() method
would return the output of the file, instead of sending it straight to the
browser. This would negate the need to capture template output using the output
buffer functions (something that I believe most frameworks end up using).
Making such a distinction would also allow web servers like Apache to treat PHP
files differently. You may create a rule in Apache to render all .phpt files as
PHP templates, rendering everything else as PHP script or application files. We
may then see mod_php implement an application mode, where one can define a
single-point of entry into their application. This could have flow-on
performance benefits, where mod_php could cache the parsed PHP, then either
fork
it on each request, or instantiate a new application class. Such a feature
would
mean frameworks wouldn't have to stuff around with .htaccess files, and would
mean that programmers don't need to add the following to the top of all their
files: if (defined('SOME_CONSTANT')) exit;
While there's momentum among the PHP developers to move forward with
modernising
the language, I think now would be a good idea to consider some of these more
fundamental changes. PHP's built-in template engine, ease of deployment, and
it's dynamic, traditional OO constructs would still remain PHP's strengths.
With all this said, I'd be happy to save such changes to a major release
intended to break legacy code, like PHP 6. I'd like to keep in mind too that
code portability isn't relevant to most people who don't intend to release
their
code as open source. Typically, those people using PHP in a business context
have control of their server. It's only shared hosting environments where
portability becomes a potential issue. All I'm saying is don't rule out ideas
based on the lowest common denominator.
Previous Comments:
------------------------------------------------------------------------
[2012-02-25 14:12:03] phpmpan at mpan dot pl
After a bit of thinking I came to a conclusion that PHARs can, in theory, have
such thing implemented. Some metadata may be included in PHAR to tell PHP that
every source file in the archive assumes "<?php" tag to be open. Since such
information is included by the author of the code, nothing can be broken.
However I don't know if it's worth being implemented. As I said before, it
gives almost nothing. Five characters is not much if one have to put dozen
lines at the begining of each file. Also PHARs, that assume opening tag to be
open, should be incompatible with older versions of PHP to prevent sending
source code to the client by accident. Too much trouble IMO.
------------------------------------------------------------------------
[2012-02-25 13:58:34] phpmpan at mpan dot pl
Sorry, I have misunderstood the "<?php>" tag. Thought it's used to *enable*
`assume_open_tag`. But, if you want to use it to disable the feature, it's even
worse. This breaks lots of existing code. Mixing PHP with HTML is an example of
bad design, but there are lots of such things and PHP devs can't just say "from
today your code is not working, because we have decided to break it". Adding
some magical sequence of characters at the begining is not a solution for this
problem. Do you imagine administrators going through all of the files on their
servers and adding "<?php>" to fix the broken code? Even harder to imagine in
case of obfuscated or PHARed code.
I believe there is enough problems with server incompatibilities already. No
need to make next one. I would be much more happy to see UTF-8 to be a standard
feature on every host. A requirement to write "<?php" doesn't bother me.
Copyright notices and namespace declarations/imports use much more space.
------------------------------------------------------------------------
[2012-02-25 13:44:12] phpmpan at mpan dot pl
So, basically, you're suggesting that programmers should write "<?php>" at the
begining of the file to not write "<?php". Blarg.
Of course this "<?php>" thing is optional. The problem is that virtually any
code has to use it to be portable. This means it's not really optional.
------------------------------------------------------------------------
[2012-02-25 09:24:21] tom at tomwardrop dot com
Are there not other directives that can break a lot of code? Remember, this
would default to off. I don't see why as a server owner, I should have this
option made unavailable purely because it can break other code. If you wanted
to
write code that worked regardless of this setting, you could do something like:
<?php
init_set('implicit_open_tag', false)
?>
Of course, for that to work then implicit_open_tag is On, the parser would have
to ignore the "<?php". The rule could be that if <?php is the first non-
whitespace sequence encountered in the file, then it's ignored.
'optional_open_tag' may therefore be a more appropriate name for this setting.
Except for legacy templates which may start with something other than <?php,
this would allow for cross-environment code. Any such template code that
breaks,
would break in a manner no different to how new features like namespaces break
in older version of PHP.
A new tag could be introduced: "<?php>". This would be shorthand for opening
and
closing a php tag, and should be placed at the top of any template file that
has
the requirement to work regardless of whether the opening tag is optional.
I hope this idea isn't dismissed on the grounds that it's difficult to
implement, because I think it's workable. Having optional opening tags would no
doubt be a step in the right direction for PHP, and I'm sure that if you didn't
have backwards compatible to be concerned about, you'd probably make opening
tags implicit with no option to make it otherwise. As I said earlier, the
decision to make the opening tag explicit was desirable at the time PHP was
conceived, but I believe it's one of those legacy decisions that needs to be re-
evaluated.
------------------------------------------------------------------------
[2012-02-25 08:50:31] [email protected]
So this would basically be a "break all existing code" .ini switch? I don't
think
that is a good idea.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61182
--
Edit this bug report at https://bugs.php.net/bug.php?id=61182&edit=1
