Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59414
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zort.net from 96.241.205.2 cause and error)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1257)
In-Reply-To: <CAORXhGK0-UCpQgsniM2=k+nK9UsAyjL5PD2ecmTB-EPxFGNKRw@mail.gmail.com>
Date: Sat, 7 Apr 2012 10:56:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <E59BE99B-EE63-4E22-A429-4E604A09FDCC@zort.net>
References: <CAORXhGLk8=bJ2TEo0OCzQCacjtGG=ZWYNuXf8Uu8oMNEm2WQ1A@mail.gmail.com> <CAGU04mLu9pniaDw3jAOR7YiX6n3Bk7sMk7T1=4PAvG5QvAZNvw@mail.gmail.com> <CAORXhGLq3ZyShNkqBsPwdabi6SkTqiE00jETiWeXK2T7Lm3gEQ@mail.gmail.com> <03FFDCA3-90B2-48CA-B102-7562E0E9CA45@zort.net> <CAORXhGK0-UCpQgsniM2=k+nK9UsAyjL5PD2ecmTB-EPxFGNKRw@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: dshadow@zort.net (John Bafford)


On Apr 7, 2012, at 10:00, Tom Boutell wrote:

> That's a good point too.
>=20
> I think this is a better proposal:
>=20
> include_code, require_code, and require_code_once would work just like
> include, require and require_once, except that the parser would start
> out in PHP mode.

Those might be nice functions to have, but ...

> .phpc is then just a convention for naming PHP files that start out
> with code - a convention that autoloaders should respect, just as they
> now respect the .php convention. "The user asked for the Monkey class,
> and I see Monkey.phpc is out there; I'll grab that with
> require_code_once."

=85 I think this isn't quite as simple as you make it out to be. Any =
autoloader that cared about bc would have to have code like

if(file_exists(.phpc)) require_code() else if(file_exists(.php)) =
require() else HCF()

There's a reason everyone settled around a single extension, and not the =
plethora we used to have (php, phtml, php3/php4, others?). Even in the =
rainbows-and-unicorns world where everyone always has an opcode cache =
and suitably tuned stat cache, that extra call to file_exists that will =
likely happen while waiting for files to be renamed and tested still =
isn't free. Also, I'm willing to bet that in the unlikely event you =
chose to drop out of PHP mode to dump a block of HTML, the awkwardness =
of a sudden ?> without a leading <?php would make the discussions about =
whether or not to have a trailing ?> at the end of files look like =
hyper-civilized discourse in comparison. (Though, it might be an =
interesting discussion regarding making the hypothetical require_code =
only (directly) include files that are pure code, with no <?php ?> tags =
allowed.)

Personally, I think the cognitive overhead the <?php ?> tags impose is =
pretty tiny. Yeah, you get weird errors sometimes, but once you =
understand what's going on, it's easy to fix (and generally easy to =
spot, if you're using version control). I really can't recall the last =
time it's happened to me and it took more than ten seconds to identify =
and fix. It's just one of the weird things about php. Every language has =
its rough edges, and in comparison, I really don't think this one even =
ranks in the top ten. There are plenty other parts of PHP that are far =
more awkward that could use addressing first (but won't, because of the =
bc break involved; haystack, meet needle).

You could also view <?php at the top of the file as a sort of magic =
number indicating the file type (such as used in many binary file =
formats: gifs always start with GIF87a/GIF89a, java class files with =
0xCAFEBABE, etc). It's unlikely a file that starts with <?php is =
anything but.

-John

> Putting this decision on the autoloader makes more sense because
> autoloaders already contain assumptions about file extensions. They
> have to in order to do their job of translating a class name to a
> particular path somewhere.
>=20
> Folks who did not care for this functionality could then choose to
> entirely ignore it. Class library developers who liked it would make
> autoloaders available that honored it, freeing end-user developers
> from thinking about it. It becomes self-contained, and people who are
> writing old-school .php standalone scripts or pages are entirely
> unaffected.
>=20
> On Sat, Apr 7, 2012 at 9:50 AM, John Bafford <dshadow@zort.net> wrote:
>>=20
>> On Apr 7, 2012, at 09:39, Tom Boutell wrote:
>>=20
>>>> =46rom the viewpoint of someone writing reusable classes, the need =
to
>>> start with <?php and reprimand anybody who accidentally puts a =
newline
>>> above it is a silly annoyance they don't experience with other =
tools.
>>>=20
>>> That said, you are making valid points, I'm not convinced myself =
that
>>> "file extensions" necessarily should or could be determined in every
>>> context. But it seems the most viable way of addressing the issue - =
if
>>> a viable way even exists. Partly I want to convince myself that this
>>> either can or can't ever be improved, and move on either way (:
>>=20
>> That "silly annoyance" doesn't seem to bother anyone who writes =
command line tools, which require the #! line specifying the command =
interpreter to be the first bytes in the file, with no leading white =
space whatsoever. Especially on unix systems (but also on the Mac), the =
file extension does not affirmatively indicate the file type or whether =
or not it can be executed.
>>=20
>> Also, from a CLI perspective, you don't want extensions in the names =
of your scripts, because then it causes problems/confusion/extra work if =
you later decide to change the language the script is written in.
>>=20
>> -John
>>=20
>> --
>> John Bafford
>> http://bafford.com/
>>=20
>>=20
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>=20
>=20
>=20
>=20
> --=20
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

--
John Bafford
http://bafford.com/