Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58662
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
MIME-Version: 1.0
Date: Tue, 6 Mar 2012 09:45:41 -0500
Message-ID: <CAGovj_NYgm0ruAoz7iA_S0fS62YJ+PpzAG+DJEnuRJRKaqkDGg@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [RFC] Namespace and Parse tags on Include and Require
From: dmgx.michael@gmail.com (Michael Morris)

I have made a wiki account with user name MichaelMorris - I don't
think I have permissions to submit an RFC as of yet.  I'll post this
here for now.  I've brought this up before, but can now simplify the
original proposal since the decision to always have <?= available
addresses much of the original problem.

These changes apply to include, require, include_once and
require_once. Two new arguments for these functions are proposed for
introduction.

The first is boolean - whether to look for php tags of any sort in the
file.  The default needs to be to expect them, this is the backwards
compatible behavior, and I'm thinking this should be 0.  1 means "no
tags in file".  This means the file to be included can be written
without any php tags at all.  This might allow the parser to speed up,
but that would be a side benefice to two goals.

One: Framework designers can more strongly enforce code separation.
For example, if a coder attempts to jump to html output in what the
framework expects to be a database interface class - which shouldn't
need to output html - there would be a syntax crash caused by this.
Naturally the obstinate coder could work around this with echo and
print.

Two:  About once a week someone on sitepoint writes a panic post about
header() not working - because of whitespace before or after the tags
- sometimes accidentally inserted.  By eliminating tags from class
definition files this problem can be be mitigated - the odds of
accidental output to the browser is lessened.

Problems
The largest problem is with IDE's. There is no current convention to
warn them that the file is pure PHP.  However, I think this can be
mitigated by adopting an extension for php include files -- *.pif,
*.iphp are two possibilities.  The language itself doesn't need to
give a care about this directly.


The second parameter is a string -- which namespace the code exists
in.  Currently a file is always imported to the root namespace.  If a
namespace is specified then the file is imported to that namespace.
If the file has a namespace definition, then that namespace becomes a
sub-namespace when imported.  Two reasons for this change

It feels weird to declare a namespace at the start of every template
file if you use php directly as a template engine instead of smarty.

Dynamic namespace resolution becomes possible.  This is a powerful but
potentially huge can of worms for the PHP programs since it allows
autoloaders can decide for itself which namespace to class requests
into.  Consider the following:

$db = new DB();

The autoloader for the framework would look in the extensions and if
there isn't a DB class, it would load the core DB into the root
namespace.  If it sees an extension it would load that instead to the
root namespace.  That file's class declaration however could read..

class DB extends Core\DB

So the autoloader would then load the Core DB class into the Core
namespace since it could do so with

require ('path/to/core/DB.php', 'Core');

This provides a powerful layer of flexibility.  It also allows a tyro
to whack their foot off.  Thoughts?

Again, as soon as I have the ability to submit an RFC I'll get this
all up on the wiki.