Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59518 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29402 invoked from network); 9 Apr 2012 17:22:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Apr 2012 17:22:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=tom@punkave.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tom@punkave.com; 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:50534] helo=mail-lb0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C8/F2-14133-2CA138F4 for ; Mon, 09 Apr 2012 13:22:17 -0400 Received: by lbbgf7 with SMTP id gf7so2028446lbb.29 for ; Mon, 09 Apr 2012 10:22:07 -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:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=nNAv3gfrzxNExNdJB/Ww0VKfelP/FYkJ6ZmX7AtzoJk=; b=Urzr9z0Qf2RTnoh2iHY1tmG8EsoeWay02H1sREXM814dqoCO6ysJwlxXPOc58vTmOT XARpmJMJDjXp6YkPzIUtDdp0zGm6jb4ZInWp0uZdcIhsWRFvwKXrIbvXyeiDB9eu4vKt 8KNbpxnIjkmJAYW7AU3xwQq11TjTJhZZ7rWkpy3v9SaoIDxgNvf+lx25NGCC/gG9RBs9 Nna7siebrGME6GAQ2MgAfo6xy326CMQJ0XwK3CoQsZOFWh8EjsbrWiUCZVbNWjawi7Et 7E/5l770AG8rw33AgQVl+1aPVuSB2aZJh3EnwHK8iH6Puw/jaND6epXmK9jr8zeM6d9E oIpA== MIME-Version: 1.0 Received: by 10.152.133.9 with SMTP id oy9mr12451534lab.43.1333992127592; Mon, 09 Apr 2012 10:22:07 -0700 (PDT) Received: by 10.152.19.106 with HTTP; Mon, 9 Apr 2012 10:22:07 -0700 (PDT) In-Reply-To: <-3647345967307864634@unknownmsgid> References: <-5877502932356715576@unknownmsgid> <-3647345967307864634@unknownmsgid> Date: Mon, 9 Apr 2012 13:22:07 -0400 Message-ID: To: Luke Scott Cc: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkmQ6Zufp0KwMVZvbkUaAnvodupY7QAy3oF8DAFggaChTwD8lQ8BwZLsPjZQInsmNk0UCfJ Subject: Re: [PHP-DEV] RFC: source files without opening tag From: tom@punkave.com (Tom Boutell) 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/now= docs. > > 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 >> --=20 Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com