Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59525
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain cywh.com from 209.85.212.42 cause and error)
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> <4F831FAE.2030208@ralphschindler.com>
In-Reply-To: <4F831FAE.2030208@ralphschindler.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 9 Apr 2012 10:51:06 -0700
Message-ID: <4775322189440202047@unknownmsgid>
To: Ralph Schindler <ralph@ralphschindler.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] RFC: source files without opening tag
From: luke@cywh.com (Luke Scott)

On Apr 9, 2012, at 10:44 AM, Ralph Schindler <ralph@ralphschindler.com> wrote:

> 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?


If this were to happen:

- I would prefer much shorter elegant constants.

- A constant for suppressing warnings thrown by include without
suppressing warnings/errors by the actual file -- I think we can all
agree @include is counter productive since it does much more that
suppress warnings thrown by include (even parse errors!).

Luke


>
> -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
>>
>>
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>