Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59429
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
Sender: kalle.php@gmail.com
In-Reply-To: <CAORXhGLk8=bJ2TEo0OCzQCacjtGG=ZWYNuXf8Uu8oMNEm2WQ1A@mail.gmail.com>
References: <CAORXhGLk8=bJ2TEo0OCzQCacjtGG=ZWYNuXf8Uu8oMNEm2WQ1A@mail.gmail.com>
Date: Sat, 7 Apr 2012 19:11:57 +0200
Message-ID: <CAJW__o3hSngtGgfbWpSJDf3NN0CSuy3p=rVfJiFVXuDgPcB2rA@mail.gmail.com>
To: Tom Boutell <tom@punkave.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: kalle@php.net (Kalle Sommer Nielsen)

Hi Tom

2012/4/7 Tom Boutell <tom@punkave.com>:
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill <?php altogether.

While I'm +0 on the idea of making <?php optional, here are some thoughts.

>
> So here is what I am seriously suggesting:
>
> * The default behavior doesn't change. The parser starts out in HTML mode.
>
> * If the CLI sees a .phpc file extension, the parser starts out in PHP
> mode (no opening <?php is required). It is still possible to shift
> into HTML mode after that with ?>.
>
> * If a require/include statement sees a .phpc file extension, the
> parser starts out in PHP mode.

CLI, or any other SAPI for the matter, doesn't care about the file
extension, as pointed out by several posts. This makes it impossible
to correctly determine the input file for a require/include statement.
The only option that would make sense is a new parser mode, which
could be specified by a CLI parameter, or by an INI option (absolutely
least favorable option, if any even wanna call it that).

A CLI argument is simple and elegant, but does require those 3 extra
keystrokes or so:
C:\> php -S bug42.php

While it does create another issue, which is that the mode is not
available to other SAPI's, and I think adding a specialized option for
each SAPI for such things will be bad, but might be a better way to do
at webserver level than php.ini level, but personally I don't like a
dynamic language that have a dynamically changed syntax,  which makes
it seem inconsistent.

Hope this was some constructive feedback if you decide to write an RFC about it.

-- 
regards,

Kalle Sommer Nielsen
kalle@php.net