Proposal for two changes to Require, Include, Require_Once and Include_Once

Before I pester the PHP wiki folks with this idea I figured I’d float it here and see if it is shot down. It’s a proposal to add two optional parameters to each of these statements. When neither new parameter is passed the system behaves as it does not insuring backward compatibility. They would change to

boolean include( string $path, [bitfield $tagstyle, [string $namespace]])

Currently files include into the global namespace. If a namespace is specified in the include param then the contents of the file include into that namespace. If the file already has a namespace definition those definitions become sub-namespaces of the namespace passed as a parameter.

To address the short tag controversy, the style of php tags can be set from these constants.

0 - PHP_TAGS_DEFAULT - (Obey the php.ini setting, this is the default)
1 - PHP_TAGS_NONE - (Whole file is considered php as if wrapped by <?php and ?>, and PHP cannot be escaped from).
2 - PHP_TAGS_LONG - (PHP longtags <?php ?> )
4 - PHP_TAGS_SHORT - (PHP short tags <? ?>, <?= ?> )


// Classic including.

// Requiring a class
require('myclass.class.php', PHP_TAGS_NONE);

// Require a class into current namespace
require('myotherclass.class.php', PHP_TAGS_NONE, __NAMESPACE__);

// Include a template using short tags.
include('template.phtml', PHP_TAGS_SHORT);

Thoughts? Stupid idea or really stupid or good or what?

Not that great of an idea. Not tested, but if you want short tags, you can probably set the relevant INI options at runtime and then include the file.

Actually, included files are subject to the current scope. Most people include them in the global scope, so weird issues generally don’t show up. However, try including a file from inside a function and have that include file declare a variable that assumes it is being included globally and you’ll get a nasty surprise when those variables suddenly vanish at the end of the function’s scope.

No, you cannot. You cannot alter the tag types at runtime. This isn’t the only thing you cannot turn on or off at runtime - a full rundown of which settings can and cannot be changed while your code is executing is covered on the PHP website. And allowing this setting to change at runtime isn’t an option because the tag type must be known when the PHP file is compiled to bytecode. The only window for this is as the include statement parses which is the reason for the suggestion.

As for changing the INI settings directly - this isn’t an option if you don’t have access to the ini file. A possible alternative is to use .htaccess, but that’s not always allowed on all servers either. PHP short tags has the problem of not being reliably on which dissuades projects seeking portability from using them as there is no safe way to use them. This is a real problem with no current solution, and my proposal to solve is not without some thought behind it.

Actually, included files are subject to the current scope.

Wrong again.

PHP is weird because variable scope and namespace scopes are resolved separately. You are right about includes where variables concerned, but I wasn’t talking about variables. Including a file starts a new namespace, and if no namespace is declared in the file then any functions or constants declared in it will be declared to the global scope.


  namespace A;

  function foo() {
    return 'foo';

  var $bar = 'bar';



  echo $bar; // "bar" -- works, variable scope continues through includes.
  echo foo();  // Fails, foo isn't defined, namespace scope changes with include.
  A\\foo(); // Will work.

My proposal solves the above by allowing this in the index.php

// Include file to current namespace (held in magic __NAMESPACE__ constant).
include('include.php', __NAMESPACE__);

Most people include them in the global scope, so weird issues generally don’t show up.

Wrong yet again. In modern PHP applications most requires occur within the scope of the autoload function. With properly built class files this isn’t an issue because the class file shouldn’t actually do anything at include time other than define the class.

Many PHP only template parsers, mine among them, use function scope to control what variables template files can see. I personally use function scope to leave the $GLOBALS untouched so that my code can run alongside any PHP application. Care to do this is becoming increasingly common, and includes where the included file can modify the global variable pool are becoming the exception rather than the rule.

That should be PHP_TAGS_MEDIUM for that particular PHP tag since you completely left out the long version of the tags.

<script language=“php”> </script>

I see how it could be useful to declare a name space dynamically, or change it. However, I doubt this would make it in because I think (don’t quote me) name spaces are not resolved at execution time, but before. That being the case would essentially mean a complete restructuring of how name spaces are handled. The rules regarding name space declaration and usage are very strict. It doesn’t seem like this is something that would be easily added in regards to the current rules in place. Furthermore, name spaces are most useful because they are concrete, unchanging. While making it possible to move classes, functions, variables and constants between name spaces adds a considerable amount of possibilities, it adds even more complexity and many ways negates one of the most beneficial aspects of concrete location.

:lol: Hah hah!!

Point taken. There’s also the ASP style tags, though I’ve never seen those used.