Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59481
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)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZUUqVaKmv7wyjUtXzD9VN=HjEwpFVOEmAHpo9QPePwWQ@mail.gmail.com>
References: <CAORXhGJwmbjw3Zze3+-oFA2Mb_Z-2owVESraNMMs57RzjRRMbA@mail.gmail.com>
	<CAGa2bXbjiNMv0g6BBZkuTtUe66gz-p8mQxRk+_0fisiJUADRgQ@mail.gmail.com>
	<CAGa2bXYhS9QCWarTKyBgv3Vnh8D8S=+Vic-XQZm0w6dqrkpf6A@mail.gmail.com>
	<CAORXhG+y0P+dM9x1_uewp0sXpHoz_4WDbjAUoRf4Auxv6FcUUQ@mail.gmail.com>
	<CAGa2bXZUUqVaKmv7wyjUtXzD9VN=HjEwpFVOEmAHpo9QPePwWQ@mail.gmail.com>
Date: Sun, 8 Apr 2012 19:14:08 -0400
Message-ID: <CAORXhGJ+ptX=ER6=u1G0OKYqF=PJ=FX-qd9KR8=M2VKK5oBtGg@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] RFC: source files without opening tag
From: tom@punkave.com (Tom Boutell)

Thanks. However, would you please fix the summary on the RFC's page to
match the summary in the actual RFC? As you have written it, it
implies that support for <?php would be completely removed. This is
not the case.

As for adding a boolean parameter to the require keyword, as the RFC
mentions there are already at least two distinctions already when
requiring files in PHP:

* include vs. require behavior (warning vs. error on failure)
* once vs. every time (require_once vs. require)

And we are proposing a third:

* start in php mode vs. start in html mode

We already have four keywords for requiring files. At this point it
does not make sense to keep introducing more keywords (we would need 8
with this change). Your boolean flag proposal keeps it to four
keywords, but as soon as someone adds another flag it will become
awkward to remember them. Since PHP does not have named parameters I
think an associative array is the best way to go (especially with the
new short syntax).

Also I don't think it makes sense to forbid shifting into html mode
later in the file, it could reduce support for the proposal needlessly
- since it already lets people who want to write clean all-PHP files
do so, and some of those people might have legitimate reasons to use
HTML mode in the scope of a function or method (where it does not
suddenly introduce whitespace without being explicitly called, etc).

But if it really came down to it I could live with an "absolutely
nothing but PHP" behavior when the code flag is true (supporting <?php
when the flag is not set is a must of course).

On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi,
>
> I talked on twitter.
> Yes, he is kidding, but he is serious, too.
>
> I've added the RFC to Under Discussion and added
> security issue description. I also added my proposal that
> controls embed mode.
>
> BTW, I don't think we need new "require_path" why don't
> we use
>
> require "file.php", ture;
>
> or some thing similar?
> I prefer to use switch, since security countermeasure is
> better to be enforced by switch.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
>
>
> 2012/4/9 Tom Boutell <tom@punkave.com>:
>> Moriyoshi was kidding, as near as I can tell (:
>>
>> To take it at face value though, the *cough* April 1st *cough*
>> proposal of Moriyoshi calls for the complete abolition of the feature
>> with no backwards compatibility with existing code that uses PHP as a
>> template language... including most popular frameworks that sensibly
>> obey a separation between class files and template files but still use
>> PHP rather than a dedicated templating language for templates.
>>
>> I don't think that's realistic (and neither did the author it
>> appears). Since PHP's usability as a template language may conceivably
>> be improved by other proposals, it is undesirable as well even if you
>> don't currently find PHP to be a suitable template language.
>>
>> Please read my proposal over carefully as it does address the obvious
>> issues that make Moriyoshi's proposal possibly less than serious in
>> intent (:
>>
>> I would oppose a php.ini flag for this as that gives us two
>> incompatible versions of the current version of the language to worry
>> about and makes the feature effectively unusable in reusable code.
>> This approach has created problems before.
>>
>> On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>> Hi,
>>>
>>> There is RFC that is written by Moriyoshi.
>>> It's not listed in RFC page, though.
>>>
>>> https://wiki.php.net/rfc/nophptags
>>>
>>> I think these should be merged.
>>>
>>> Regards,
>>>
>>> --
>>> Yasuo Ohgaki
>>> yohgaki@ohgaki.net
>>>
>>>
>>>
>>> 2012/4/9 Yasuo Ohgaki <yohgaki@ohgaki.net>:
>>>> Hi,
>>>>
>>>> Moriyoshi has created same entry on 4/1, but
>>>> it seems it was deleted =A0already.
>>>>
>>>> Anyway, he had a patch for it.
>>>>
>>>> https://gist.github.com/2266652
>>>>
>>>> As I mentioned in other thread, we should better to have
>>>> a switch to disable embed mode for security reasons.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Yasuo Ohgaki
>>>> yohgaki@ohgaki.net
>>>>
>>>>
>>>>
>>>> 2012/4/9 Tom Boutell <tom@punkave.com>:
>>>>> I have written an RFC proposing backwards-compatible support for
>>>>> source files without an opening <?php tag:
>>>>>
>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>>
>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>>> what the requirements are to get it added to the "Under Discussion"
>>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>>> do whatever is required.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> Tom Boutell
>>>>> P'unk Avenue
>>>>> 215 755 1330
>>>>> punkave.com
>>>>> window.punkave.com
>>>>>
>>>>> --
>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>
>>
>>
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.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