Req #61182 [NEW]: Assume Opening PHP Tag

From: Date: Sat, 25 Feb 2012 08:37:03 +0000
Subject: Req #61182 [NEW]: Assume Opening PHP Tag
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-167817@lists.php.net to get a copy of this message 
From:             
Operating system: 
PHP version:      5.4.0RC8
Package:          *Configuration Issues
Bug Type:         Feature/Change Request
Bug description:Assume Opening PHP Tag

Description:
------------
PHP is probably the only language I know which requires an opening tag (i.e
<?
php). It's one of those things with PHP that people rarely question. While
PHP 
is a rather unique programming language in that it's basically a templating

engine at its core, I feel that requiring the opening <?php is not catering
to 
the majority of the use cases. Instead, I'd rather PHP assume that the file

being executed has PHP from line 1 which is most commonly the case. In the
less 
common scenario where PHP is not the first text encountered, the user would
need 
to close the assumed PHP execution block with a ?>.

In the early days, when web pages were mostly static, and PHP was used to
add 
dynamic elements, it made sense to require an opening tag to drop-into PHP

execution. These days however, the opposite is more often the case. You
normally 
have a complete PHP web application, into which HTML and other static text
is 
inject, rather than injecting dynamic elements into static web pages.

What I'd like to see is a new directive added to php.ini. Call it what you
want, 
e.g. assume_open_tag or omit_open_tag.

This would require a few changes in coding practice. For example, if 
omit_open_tag is On, then the behaviour of the include() and require() 
constructs will change. They too will assume the files being required
contain 
PHP from line 1. Programmer will not longer be able to use include() and 
require() to load file contents, instead the programmer would have to use 
file_get_contents or some other alternative, though this would arguably a
good 
thing, as using require() and include() to load and output non-php could be

vulnerability, hence it's already bad practice to use include/require() to
load 
non-PHP files.

I think this change would be consistant with some of the changes made in
5.4 
which demonstrates PHP embracing modern programming idioms from other
languages. 
Ideally, I'd like this to become the default behaviour of PHP, though
obviously 
for at least the first major release, it would of course be defaulted to
Off.

Thoughts?


-- 
Edit bug report at https://bugs.php.net/bug.php?id=61182&edit=1
-- 
Try a snapshot (PHP 5.4):            https://bugs.php.net/fix.php?id=61182&r=trysnapshot54
Try a snapshot (PHP 5.3):            https://bugs.php.net/fix.php?id=61182&r=trysnapshot53
Try a snapshot (trunk):              https://bugs.php.net/fix.php?id=61182&r=trysnapshottrunk
Fixed in SVN:                        https://bugs.php.net/fix.php?id=61182&r=fixed
Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61182&r=needdocs
Fixed in release:                    https://bugs.php.net/fix.php?id=61182&r=alreadyfixed
Need backtrace:                      https://bugs.php.net/fix.php?id=61182&r=needtrace
Need Reproduce Script:               https://bugs.php.net/fix.php?id=61182&r=needscript
Try newer version:                   https://bugs.php.net/fix.php?id=61182&r=oldversion
Not developer issue:                 https://bugs.php.net/fix.php?id=61182&r=support
Expected behavior:                   https://bugs.php.net/fix.php?id=61182&r=notwrong
Not enough info:                     https://bugs.php.net/fix.php?id=61182&r=notenoughinfo
Submitted twice:                     https://bugs.php.net/fix.php?id=61182&r=submittedtwice
register_globals:                    https://bugs.php.net/fix.php?id=61182&r=globals
PHP 4 support discontinued:          https://bugs.php.net/fix.php?id=61182&r=php4
Daylight Savings:                    https://bugs.php.net/fix.php?id=61182&r=dst
IIS Stability:                       https://bugs.php.net/fix.php?id=61182&r=isapi
Install GNU Sed:                     https://bugs.php.net/fix.php?id=61182&r=gnused
Floating point limitations:          https://bugs.php.net/fix.php?id=61182&r=float
No Zend Extensions:                  https://bugs.php.net/fix.php?id=61182&r=nozend
MySQL Configuration Error:           https://bugs.php.net/fix.php?id=61182&r=mysqlcfg

Thread (11 messages)

« previous php.bugs (#167817) next »