Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59405
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <03FFDCA3-90B2-48CA-B102-7562E0E9CA45@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>
Date: Sat, 7 Apr 2012 10:00:21 -0400
Message-ID: <CAORXhGK0-UCpQgsniM2=k+nK9UsAyjL5PD2ecmTB-EPxFGNKRw@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: tom@punkave.com (Tom Boutell)

That's a good point too.

I think this is a better proposal:

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.

.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."

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.

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.

On Sat, Apr 7, 2012 at 9:50 AM, John Bafford <dshadow@zort.net> wrote:
>
> On Apr 7, 2012, at 09:39, Tom Boutell wrote:
>
>>> From 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.
>>
>> 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 (:
>
> That "silly annoyance" doesn't seem to bother anyone who writes command l=
ine tools, which require the #! line specifying the command interpreter to =
be the first bytes in the file, with no leading white space whatsoever. Esp=
ecially 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.
>
> Also, from a CLI perspective, you don't want extensions in the names of y=
our scripts, because then it causes problems/confusion/extra work if you la=
ter decide to change the language the script is written in.
>
> -John
>
> --
> John Bafford
> http://bafford.com/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--=20
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com