php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #32436 'phpx' making a first class scripting language (default way to drop <?php ?>)
Submitted: 2005-03-23 22:23 UTC Modified: 2005-04-14 17:23 UTC
From: sam_bravard at yahoo dot com Assigned:
Status: Wont fix Package: Feature/Change Request
PHP Version: 5.0.3 OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2005-03-23 22:23 UTC] sam_bravard at yahoo dot com
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? 







Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-03-24 01:44 UTC] rasmus@php.net
Mostly a troll.  And we already have php -r
 [2005-04-12 19:58 UTC] sam_bravard at yahoo dot com
Not a troll at all, please take a thoughtful second before you flip the bozo bit.

Ruby, Python, Perl, Tcl, bash, sh, all run undecorated code by default from their command line tools.

So where does php stand?  It takes exactly the opposite approach, for no good reason except for history.

Let's be user-centric here.  What are web tags doing in a command line script?  What compelling benefit do I get from adding '<?php code... ?>'?

So the proposal above is a good compromise, make it easy to get what they want and show that you care about it as a default option:

Here's some psuedocode to show how trivial this is to do at the command line:

Add a quick test to argv[0] for the name 'phpx' and turn on '-r' mode by default.

Add 1 line to the make file that does a hard link from 'php' to 'phpx'.  And one line to make install to add 'phpx'.  

From a web services point of view, look at how people program ASP.NET pages.  The .aspx file is full of tags, the .aspx.cs file is full of straight code.   

If you try to create a similar model in PHP (see www.xisc.com) then people have to remember to wrap all their classes in <?php ?> start/end blocks... and god forbid there's a space before or after the tags and the framework output fails because PHP will blindly copy whitespace.

Having a framework fail because someone types an extra space?  That's not taking a user-centric approach at all.  It's an uncommon requirement, and people entering php from any other language just find it a frustrating quirk.

Let's concentrate on the end users here.  It's who PHP is for after all... let's make their lives simpler and make it compelling to let PHP spread into all sorts of other uses.

So let's revisit the points:

*) A default script-only mode on the command line (say 'phpx' or whatever you like - just easy to type, doesn't require any other arugments unless the user wants something special)

*) A default script-only extension (.phpx? .php-class?, or something better) that doesn't require open/close tags and isn't sensitive to whitespace at the front or end of the file.

Trivial stuff to fix, and it makes a huge difference in people's perception/enjoyment/willingness to spread the PHP word.

And seriously, if someone is clearly trying to help the project, let's ease up with the knee-jerk name calling.
 [2005-04-13 18:16 UTC] derick@php.net
We have "php -r" which we deem enough. If it's not good enough for you you can always make a shell script around it.
 [2005-04-14 17:23 UTC] sam_bravard at yahoo dot com
How do you enable 'php -r' for web page processing through mod_php on apache?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 06:01:29 2024 UTC