Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59424
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.161.170 as permitted sender)
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> <7019423255875772333@unknownmsgid>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <7019423255875772333@unknownmsgid>
Message-ID: <93A21C4E-C811-4D2A-9304-6DDF1E8994FB@punkave.com>
Date: Sat, 7 Apr 2012 12:04:23 -0400
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: tom@punkave.com (Tom Boutell)

A thoughtful suggestion. But the trouble with a php.ini setting is that you c=
an't tell if it is enabled when writing your class file. That makes it impos=
sible to write portable libraries. The keywords would always be available. A=
nd no one has to type them outside of an auto loader (:=20

Sent from my iPhone

On Apr 7, 2012, at 11:46 AM, Luke Scott <luke@cywh.com> wrote:

> On Apr 7, 2012, at 7:00 AM, Tom Boutell <tom@punkave.com> wrote:
>=20
>> 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.
>>=20
>> .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."
>>=20
>> 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
> Tony I think your idea has some merit. If it were up to me I'd remove
> <?php all together. It really is bad practice to mix HTML into code.
>=20
> But I feel that adding new keywords is not the way to do it.
> Personally I'd like to see a php.ini setting to disallow the ending ?>
> tag and assume .php files just have PHP code. The starting <?php tag
> would be optional. White space would be ignored and non-white space
> characters before <?php would throw a fatal error.
>=20
> Doing it this way would disallow bad practices but still make existing
> PHP scripts compatible.
>=20
> I think that doing that would be quite reasonable. Those who complain
> about it likely ignore industry best practices anyway. This option
> could be turned off by default at first, made default later, and then
> ?> be deprecated all together.
>=20
> So with this option enabled ?> is forbidden, <?php is optional, and
> the text before <?php is handled differently - white spaces ignored,
> text before throws an error (unless it's a shebang line in cli mode).
>=20
> Hopefully that made sense. Does this sound good to you?
>=20
> I'm sorry you had to endure such a nasty troll. I am so sick of self
> righteous bullies who think they know it all.
>=20
> Luke
>=20
>>=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 l=
ine tools, which require the #! line specifying the command interpreter to b=
e the first bytes in the file, with no leading white space whatsoever. Espec=
ially on unix systems (but also on the Mac), the file extension does not aff=
irmatively 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 y=
our scripts, because then it causes problems/confusion/extra work if you lat=
er 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
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>>=20
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>=20