Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59523
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ralphschindler.com from 209.85.161.170 cause and error)
Message-ID: <4F831FAE.2030208@ralphschindler.com>
Date: Mon, 09 Apr 2012 12:43:10 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAORXhGJwmbjw3Zze3+-oFA2Mb_Z-2owVESraNMMs57RzjRRMbA@mail.gmail.com> <-5877502932356715576@unknownmsgid> <CAORXhGLPdAie6UFq+daJhUmDUqp7RaFFLa596XdzdtuCddf0Jw@mail.gmail.com> <-3647345967307864634@unknownmsgid> <CAORXhGKjg_L11dFGNHNfNygDH018=ZhytAy1vH+Ei8QHfry=cA@mail.gmail.com> <CAORXhG+K3XML-47+FDYdL5D717wDX7c59Pz8KgqjcP16+Ad12w@mail.gmail.com>
In-Reply-To: <CAORXhG+K3XML-47+FDYdL5D717wDX7c59Pz8KgqjcP16+Ad12w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: source files without opening tag
From: ralph@ralphschindler.com (Ralph Schindler)

Hey Tom,

An idea, why not overload require/include with a second parameter that 
simply enforces an include mode.  For example

// in some autoloader (include, requires, and *_onces)
include $pathToFile, INCLUDE_MODE_PHP_ONLY;

This would tell the parser/executor to start in PHP mode and never leave 
it, that way, ending tags would throw a runtime/execution error.

Other constants and behaviors could be:

   INCLUDE_MODE_PHP_START;
   INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior)

This would have the least amount of impact on BC, and seeminlyg would be 
a friendly change to the lexer/syntax.

Thoughts?

-ralph



On 4/9/12 12:23 PM, Tom Boutell wrote:
> Also, your objection - that 'require_code' is confusing - would most
> likely be an issue for a handful of people who write autoloaders.
> Those clean PHP class files are almost always autoloaded.
>
> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell<tom@punkave.com>  wrote:
>> I see what you're saying, but you're proposing a new keyword to
>> include code that does what plain old 'require' does now (assuming
>> it's not a nice clean class file that is being included). Which means
>> that valid code today is busted code once this feature comes out. That
>> seems like a very hard sell.
>>
>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott<luke@cywh.com>  wrote:
>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell<tom@punkave.com>  wrote:
>>>
>>>> It sounds like you are proposing to gradually kill the use of PHP for
>>>> templating entirely, which I don't think is something people would
>>>> vote for.
>>>
>>> I'm not saying that at all. I'm saying that PHP code should be clearly
>>> separated from template code.<?php should be optional at the start of
>>> the file and IF a keyword should be added it should be for templates
>>> and short-tags.
>>>
>>> 99% of modern PHP code is going to be classes that start with<?php
>>> and omit the ending ?>  (since PHP 5 due to how easy it is for white
>>> space to end up on the tail end of a file). this is even the case with
>>> procedural code.
>>>
>>> Half the PHP frameworks out there have their own template engine
>>> because they can do a lot more than what short tags offer. Example:
>>> Twig offers template inheritance.
>>>
>>> Introducing a keyword for PHP code without the<?php tag is
>>> impractical. It makes much more sense to have a keyword for templates.
>>>
>>> For non-template code the starting<?php tag should always work as it
>>> has before for backwards compatibility. The difference is you cannot
>>> use ?>  and text before the opening<?php tag is either ignored or
>>> throws an error.
>>>
>>>> I sometimes use perfectly good older frameworks that do use
>>>> .php files for templating in a reasonable way, and I'm one of the
>>>> advocates for migrating away from starting everything with<?php. I
>>>> would have to vote against it myself.
>>>
>>> And those files can be included with something like require_template
>>> or you can turn off the option in the ini file.
>>>
>>> The point is in EITHER MODE a php file that starts with<?php will
>>> work as it did before. The new mode would just disallow you to break
>>> out of PHP code with ?>.
>>>
>>>> There's no reason to kill good
>>>> code that passes its tests just because it uses inline HTML. I won't
>>>> even know I have that code in my project from some third party library
>>>> until I find out the hard way. No, just no. (:
>>>
>>> I'm not trying to kill anything. In fact what I'm proposing would be a
>>> smooth transition to something that is already done. The difference is
>>> at some point you won't be able to do this:
>>>
>>> <?php
>>> class Object
>>> {
>>>     public function output()
>>>     {
>>> ?>
>>> Print me!
>>> <?php
>>>     }
>>> }
>>>
>>> I cringe every time I see this. There is no excuse since we have here/nowdocs.
>>>
>>> For people that use PHP as a template there can be other options. I'm
>>> not totally against a new keyword, but I am against a new keyword for
>>> including normal PHP code. It just doesn't make sense. No matter what
>>> you name it (require_code, require_file, require_path) it's damned
>>> confusing. If you did it the other way around its much clearer:
>>> require_template.
>>>
>>> With require_template you're also free to expand template
>>> functionality while keeping code clearly separated.
>>>
>>>> I did propose one new keyword, but by proposing one keyword with a
>>>> future-friendly syntax instead of four new keywords I'm attempting to
>>>> help with the pollution problem.
>>>
>>> It's not as much as adding a keyword as it is what keyword you're adding.
>>>
>>> I hope the way I've explained things makes sense.
>>>
>>> Luke
>>>
>>>>
>>>> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott<luke@cywh.com>  wrote:
>>>>> Tom,
>>>>>
>>>>> As I've said before I don't think new keywords are the answer. They
>>>>> will just pollute the language even further.
>>>>>
>>>>> I also don't think an ini setting is a bad thing either. It is often
>>>>> used in PHP as a way to transition from way of doing things to
>>>>> another. First you introduce it with it being off by default, then on
>>>>> by default, then deprecate the old behavior. It's quite normal in
>>>>> PHP's history.
>>>>>
>>>>> In another email someone mentioned doing two rfcs. In both cases are
>>>>> we talking about removing<?php ? Because it's become somewhat
>>>>> confusing to keep track of what is being talked about. If that is the
>>>>> case, continue reading.
>>>>>
>>>>> I would prefer the starting<?php tag be optional rather than removed.
>>>>> Just explicitly forbid the ending ?>  tag and treat text before the
>>>>> opening<?php tag differently. Perhaps ignore it (rather than print)
>>>>> or throw an error.
>>>>>
>>>>> That is at least how I would prefer the "code" mode as most
>>>>> non-template files only start with<?php. It allows for backwards
>>>>> compatibility.
>>>>>
>>>>> If you must add keywords it should be something like require_template
>>>>> NOT require_code/require_file. Templates are the exception, not the
>>>>> norm.
>>>>>
>>>>> Luke Scott
>>>>>
>>>>> On Apr 8, 2012, at 9:32 AM, Tom Boutell<tom@punkave.com>  wrote:
>>>>>
>>>>>> 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
>>>>
>>
>>
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>
>
>