Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60003
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSyUHebUTi3zfSPkDvapuG902rHnz6Pi=yS5WUdEYMZqKQ@mail.gmail.com>
References: <CAEZPtU52Ayb6fnLSaZdQ+LHk1hEh3X1tJUO3NWUg3befgSAM1w@mail.gmail.com>
 <CAGa2bXZ6W7=Pi+SP4b6c510bWbM9hEjq90_s63bBxbc9n9vsoQ@mail.gmail.com>
 <CAKOpQSxAd6sG8BHWn+dUUz4rAdChhUA+HXyJGpeoZ8GmJKRM0w@mail.gmail.com>
 <CAL0xaBGSbBAw3XEwzNOxzoNoFAHDQVDFH9Zw7ju5VKNtA12UYA@mail.gmail.com> <CAKOpQSyUHebUTi3zfSPkDvapuG902rHnz6Pi=yS5WUdEYMZqKQ@mail.gmail.com>
Date: Mon, 16 Apr 2012 16:38:10 +0300
Message-ID: <CAL0xaBE19-1C78N-ks=Vd+CFyHFnM2xCdojJbDSCF301npy3XQ@mail.gmail.com>
To: Kris Craig <kris.craig@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, Pierre Joye <pierre.php@gmail.com>, 
	PHP internals <internals@lists.php.net>, Tom Boutell <boutell@boutell.com>, 
	Moriyoshi Koizumi <moriyoshi@php.net>
Content-Type: multipart/alternative; boundary=14dae93410eb29d01904bdcbf030
Subject: Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--14dae93410eb29d01904bdcbf030
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

16 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2012 =D0=B3. 11:05 =D0=BF=D0=BE=D0=
=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Kris Craig <kris.=
craig@gmail.com>=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> Arvids,
>
>
> On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks <arvids.godjuks@gmail.co=
m
> > wrote:
>
>> What happened with the proposal/RFC for expanding include/require with
>> additional optional second param to allow for developers to define in pl=
ace
>> if he want's a pure PHP file to be included or a template file with dire=
ct
>> HTML output?
>> I like that proposal and take it over any other, because it gives
>> developer a choice. And if things do not go the right way and he ends up
>> screwing up somewhere - he is able to fall back to the old mode just by
>> modifying the include/require statement (and in a MVC framework with
>> autoload usage that would be 1-2 places in the whole project).
>> All that stuff with keywords, removing <?php tags and using special
>> extensions require a continuous effort from the developers, additional
>> support from the IDE/editors/other tools. Do we really need all that jus=
t
>> to give people the ability to load their scripts as a pure PHP code?
>> To my mind a modification to the include/require statements is all there
>> is required to add that extra thing that Kris want's so badly and does n=
ot
>> require to change your habbits, IDE templates, waiting for IDE/editors/W=
EB
>> source code highlight libraries/source analyzers/etc to catch up with th=
e
>> change.
>> There is also a question I just raised that is not yet answered that the
>> keyword/extension thing can just break the valid performance tweak
>> technique, that is used extensively in any project with big code base.
>>
>
> That may very well be the method proposed in my RFC, too.  I haven't made
> up my mind on that point as I'd like to cover the pros/cons a little more
> in depth (including the potential perf issue you just raised).  A handler
> approach or something similar will still be necessary as well, since one
> key reason for my RFC was to make it so that these scripts could be
> executed directly via the webserver.  But as for determining how PHP itse=
lf
> can identify a .phpp file, I think the three best options are:  Create ne=
w
> tags, create new keywords, or create new parameters to existing keywords.
>  I keep bouncing back and forth on which one I think is best, which tells
> me that I need to hear more debate on that.  Thoughts?
>
> --Kris
>
> I would encourage you to take a deep look into modifying the
include/require statements, because for all the issues popped out with
.pphp and keywords they just don't exist with include/require. And there is
no need to remove the <?php tags in source files - just make sure they
start first thing in the file and there is no ?> at the end and hey (for my
case - my IDE removes all leading and trailing spaces on file save), your
include 'file', PHP_SOURCE_ONLY; works fine, but including a template
fails  (as does an image with embedded <?php ?> tags uploaded through a
security hole) .
It's clean (although some BC break would occur, but I think it's minor),
simple and 100% voluntary. Any decently written 3rd party library will work
without any modification (well, removing trailing ?> is a matter of simple
script if required, but I haven't seen people putting ?> in the end for
years).

--14dae93410eb29d01904bdcbf030--