Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58725
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.241 as permitted sender)
To: Michael Morris <dmgx.michael@gmail.com>, PHP Internals List
	<internals@lists.php.net>
Date: Wed, 7 Mar 2012 04:26:20 -0500
Thread-Topic: [PHP-DEV] Re: [RFC] Namespace and Parse tags on Include and
 Require
Thread-Index: Acz7spRTY1KOWIaURmSFGfjXs/T4/QAjZmpA
Message-ID: <A633CF2D7C7BED41B41F1E64F25507B8069DC47164@MAILR001.mail.lan>
References: <CAGovj_NYgm0ruAoz7iA_S0fS62YJ+PpzAG+DJEnuRJRKaqkDGg@mail.gmail.com>
 <CAGovj_N+O+UfZw8WqRg3Bp8bNSeSBF3hi_2frPgEBThZP6Nt1g@mail.gmail.com>
In-Reply-To: <CAGovj_N+O+UfZw8WqRg3Bp8bNSeSBF3hi_2frPgEBThZP6Nt1g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] Re: [RFC] Namespace and Parse tags on Include and
 Require
From: johncrenshaw@priacta.com (John Crenshaw)

> Ok, with Hannes help I have the RFC up now.
>
> https://wiki.php.net/rfc/changes_to_include_and_require

WRT tagless files, in addition to the issues already raised by others:
- What about script execution? You'll still need a shebang (linux) or to re=
gister the extension (Windows). Having a special shebang but making the <?p=
hp still optional seems silly. Conversely not being able to start in script=
 mode from the place most likely to only have script also makes no sense.
- Apache will also not like these files very much. Possible to work around =
if you use a different extension, but will present a huge problem for legac=
y server configurations (which will still be ubiquitous for years after any=
 such change).
- Autoloaders. Even if an extension convention is adopted this will be horr=
ibly painful. Consider the work and additional (twice as many!!!) disk acce=
sses required to make a simple autoloader for PEAR convention libraries wor=
k with both formats.
- General code interoperability is a serious problem here too. If such a ch=
ange were adopted developers would have to open and examine any file prior =
to inclusion to ensure that they know which format the file is in. Using th=
e wrong type of include would be a huge problem.
- Closing the tag that wasn't opened in the middle of such a file would be =
incredibly strange
- I expect that this would create problems with the variety of opcode cache=
s out there (since caches would now need to become aware of which mode of f=
ile they have cached vs. which mode the file is getting included in).

To me the autoloader and interoperability issues are the most critical beca=
use they directly impact usability and performance basically everywhere.

John Crenshaw
Priacta, Inc.