Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59994
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH7qjnwQk1kvOYg67tU-p+YSV8za6-k-56JYXiu1xSHHxQ@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> <CAH-PCH7qjnwQk1kvOYg67tU-p+YSV8za6-k-56JYXiu1xSHHxQ@mail.gmail.com>
Date: Mon, 16 Apr 2012 12:31:14 +0300
Message-ID: <CAL0xaBHo0aTCBEM9YRbXs8nQAC5t5CnHEo=nBaGyNVVMfZ03MQ@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Kris Craig <kris.craig@gmail.com>, 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=90e6ba613862f89e2304bdc87ca2
Subject: Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--90e6ba613862f89e2304bdc87ca2
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:24 =D0=BF=D0=BE=D0=
=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Ferenc Kovacs <ty=
ra3l@gmail.com>=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

>
>
> On Mon, Apr 16, 2012 at 9:46 AM, Arvids Godjuks <arvids.godjuks@gmail.com=
>wrote:
>
>> What happened with the proposal/RFC for expanding include/require with
>> additional optional second param to allow for developers to define in
>> place
>> 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.
>
>
> there is a valid issue which was discussed on irc yesterday:
> because include/require is a language construct, not a method,  one is
> allowed, even advised to write the include/require calls without putting
> out the parentheses.
> if we introduce additional arguments for include/require, the following
> code will break:
> echo include 'foo.bar', 'baz';
> as currently it was interpreted as
> echo include('foo.bar'), 'baz';
> ofc. we could make that the additional params to include, require would
> only used, if the parentheses are uses, but that would make require/inclu=
de
> inconsistent with every other language construct, where the parentheses i=
s
> optional.
> so we either accept this BC, or not pursue this option, but go with the
> new functions/opcodes like include_code/require_code or similar.
>
> --
> Ferenc Kov=C3=A1cs
> @Tyr43l - http://tyrael.hu
>

That's sad really, to be honest.
I wonder if people even use this:

> echo include 'foo.bar', 'baz';
> as currently it was interpreted as
> echo include('foo.bar'), 'baz';

I even didn't know it worked that way and if I saw code like this before
today I would consider it an error (I would discover that it actually
works, but I definitively would rewrite that part in two lines as distinct
operators them with ; instead of , between them)

Maybe it's not that big deal and a BC break would not impact things a lot.
What do you think?

--90e6ba613862f89e2304bdc87ca2--