Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59519 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30066 invoked from network); 9 Apr 2012 17:23:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Apr 2012 17:23:10 -0000 Authentication-Results: pb1.pair.com header.from=tom@punkave.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tom@punkave.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.217.170 as permitted sender) X-PHP-List-Original-Sender: tom@punkave.com X-Host-Fingerprint: 209.85.217.170 mail-lb0-f170.google.com Received: from [209.85.217.170] ([209.85.217.170:41800] helo=mail-lb0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B3/23-14133-CFA138F4 for ; Mon, 09 Apr 2012 13:23:09 -0400 Received: by lbbgf7 with SMTP id gf7so2029202lbb.29 for ; Mon, 09 Apr 2012 10:23:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type:content-transfer-encoding:x-gm-message-state; bh=zdzUD+eVshNNQ8ua81r5pm6nM7l9H8+e/YLCwQAl4QY=; b=OrmvuF7cRJntrO4cztyDaRhzA2O8cT88igmFhS7ys8dbZNtya0Ia5V1BNneOSPEMcs 5cBcTjQqvqWwL0U6nCfTnb9gFXZzI+bYjdGZ/NSrobvbKUwx6J2B20HgDcWDxdsyBwCd 3MtIcpmu9xoSPoxDc4fQspFbluHXeIU6L/+PQZwLBvkdPhqai3Eh/7HeJIvKSEBBWOD4 IOzeczohqMXPPdNswq1hPClE7zYKwGGy7corTTgam38jkNuXojXcGoC4DACfdIUz3gwd NCzqe6bkeQpkCBJ7ogOcnf4q3GyB/2OeMqmo9XhIzhfcI4v9zKn98pfyv1rGKVxvid62 6jUQ== MIME-Version: 1.0 Received: by 10.152.129.74 with SMTP id nu10mr12408150lab.50.1333992185526; Mon, 09 Apr 2012 10:23:05 -0700 (PDT) Received: by 10.152.19.106 with HTTP; Mon, 9 Apr 2012 10:23:05 -0700 (PDT) In-Reply-To: References: <-5877502932356715576@unknownmsgid> <-3647345967307864634@unknownmsgid> Date: Mon, 9 Apr 2012 13:23:05 -0400 Message-ID: Cc: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk+kH1+uwZ43QakuOUR2rWxdHtzTQBn93y2SaIsJL2q0jalAGwtPZ9U3JEEGwJL/NCy9yHC Subject: Re: [PHP-DEV] RFC: source files without opening tag From: tom@punkave.com (Tom Boutell) 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 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 wrote: >> On Apr 9, 2012, at 9:16 AM, Tom Boutell 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. > 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 > 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 > impractical. It makes much more sense to have a keyword for templates. >> >> For non-template code the starting > has before for backwards compatibility. The difference is you cannot >> use ?> and text before the opening > 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 >> 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 > 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: >> >> > class Object >> { >> =A0 =A0public function output() >> =A0 =A0{ >> ?> >> Print me! >> > =A0 =A0} >> } >> >> I cringe every time I see this. There is no excuse since we have here/no= wdocs. >> >> 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 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 >>> confusing to keep track of what is being talked about. If that is the >>>> case, continue reading. >>>> >>>> I would prefer the starting >>> Just explicitly forbid the ending ?> tag and treat text before the >>>> opening >>> or throw an error. >>>> >>>> That is at least how I would prefer the "code" mode as most >>>> non-template files only start with >>> 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 wrote: >>>> >>>>> I have written an RFC proposing backwards-compatible support for >>>>> source files without an opening >>>> >>>>> 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 --=20 Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com