#32436 [NEW]: 'phpx' making a first class scripting language (default way to drop <?php ?>)

From: Date: Wed, 23 Mar 2005 21:23:03 +0000
Subject: #32436 [NEW]: 'phpx' making a first class scripting language (default way to drop <?php ?>)
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-75770@lists.php.net to get a copy of this message
From: sam_bravard at yahoo dot com Operating system: PHP version: 5.0.3 PHP Bug Type: Feature/Change Request Bug description: 'phpx' making a first class scripting language (default way to drop <?php ?>) Description: ------------ I think it's time PHP had a default way to run PHP files without having to wrap them in <?php ?> tags. PHP5 is really a great general purpose scripting language. It would be great that 'out of the box' it started acting like a real scripting language and leave it's need of wrapper page tags and the output side effects behind. Thoughts: *) Create a new 'phpx' (other name?) command line tool that will default to not needing page tags. - or change the default behavior of the 'php' command to accept files without enclosed '<?php ?>' and make a command line option to allow it. But this will break existing code, so 'phpx' seems like a better choice. *) Add a new 'phpx' httpd mime-type handler that processes php files as pure code without the wrapper tags. Rationale: phpx command line tool: *) php should look just like any other scripting lang from the command line. Make the barrier to entry low and make the model consistent with what everyone expects. Things like trying to remember to close a '%>' tag in a large file of php code just makes users frustrated. .phpx web handler: *) When designing ASP.NET like web frameworks like Prado (see http://www.xisc.com/) the code gets split between a markup file which isn't PHP code at all (parsed custom tags in an YourPage.inc file), and a backing class YourPage.php which is pure php classes and has no need for generating non programmatic page output. Example silly but serious failure #1: God forbid the user adds any extra whitespace at the end of the file after the closing php '%>' tag, and the entire HTTP response rendering chain breaks because by default PHP copies everything to the output stream and those 'spaces' before the HTTP header is sent causes the response to fail. In a real 'language' file, extraneous whitespace shouldn't crash your web application. This class of potential errors just seems plain silly and would be great if php could by default ignore. Thoughts? -- Edit bug report at http://bugs.php.net/?id=32436&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32436&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32436&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32436&r=trysnapshot51 Fixed in CVS: http://bugs.php.net/fix.php?id=32436&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=32436&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32436&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32436&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32436&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32436&r=support Expected behavior: http://bugs.php.net/fix.php?id=32436&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32436&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32436&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=32436&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32436&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=32436&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32436&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32436&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32436&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32436&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32436&r=mysqlcfg

« previous php.bugs (#75770) next »