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 <l...@cywh.com> wrote:
> On Apr 9, 2012, at 9:16 AM, Tom Boutell <t...@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 <l...@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 <t...@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
