Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59527 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49760 invoked from network); 9 Apr 2012 18:26:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Apr 2012 18:26:03 -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.213.170 as permitted sender) X-PHP-List-Original-Sender: tom@punkave.com X-Host-Fingerprint: 209.85.213.170 mail-yx0-f170.google.com Received: from [209.85.213.170] ([209.85.213.170:60585] helo=mail-yx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 89/53-34074-AB9238F4 for ; Mon, 09 Apr 2012 14:26:02 -0400 Received: by yenl5 with SMTP id l5so2266145yen.29 for ; Mon, 09 Apr 2012 11:25:59 -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 :content-type:content-transfer-encoding:x-gm-message-state; bh=jPjJ0I291aS7TE2RO4djleF6MyK+wHQM5S0RTYFxb6w=; b=NsGlE2TiFYn9LHXKyzdN6Y7j5J0msySJG0wcL6cD4mQvE/wu8EYuWKOivZsotZ8zP0 fSzlpM5AQUvNTxdY0AgyjZRtL676VBqOIGvKhr824hV8CQJpNSdR0aqzeb09hycBQLBB f7yuhCPYKyWnNylmRWcvj/2AumSYzUnzaEXhi6yWzKLMMXLkh/OU2r0fcUT+of8+lVot bGEWW/yqUL1OzY8ILKBgrQD7GWiCUvL8Hy0Muu21ViJy1m89MddVEZzBqPgrBZm9f6Xi dkDqkWR0SSOtA/nFJ04yjCH1c17rWMn7/5YqCez/l6QzTC3aNHIxFvKhGl4lrgyu9CMy lMqg== MIME-Version: 1.0 Received: by 10.236.78.2 with SMTP id f2mr6773599yhe.118.1333995959778; Mon, 09 Apr 2012 11:25:59 -0700 (PDT) Received: by 10.100.35.16 with HTTP; Mon, 9 Apr 2012 11:25:59 -0700 (PDT) In-Reply-To: <4775322189440202047@unknownmsgid> References: <-5877502932356715576@unknownmsgid> <-3647345967307864634@unknownmsgid> <4F831FAE.2030208@ralphschindler.com> <4775322189440202047@unknownmsgid> Date: Mon, 9 Apr 2012 14:25:59 -0400 Message-ID: To: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQla+d6BdK+tCXrgmyEboCUHeRFyoQ5IdKawVsp5afX6Eh2+5S/wYe1O220UZwkv2zFN5JeY Subject: Re: [PHP-DEV] RFC: source files without opening tag From: tom@punkave.com (Tom Boutell) Ralph, you make good points. And Luke's opposition to my new keyword is probably going to be shared by others (like Chris who just chimed in). So the more I think about it, the more a set of constants that can be OR'd together is a better idea than my associative array proposal. And it's best to keep the original four keywords, adding the second, optional parameter as a way of passing a combination of flags that alter their behavior. Also that set of bits could include the 'once' and 'warning' flags, so if you really want to just use the 'require' keyword and determine dynamically which behavior you get, you can. So there are no new keywords needed. Also, the presence of any bit that is not recognized by this version of PHP should be an error. It's better to stop than to completely misparse a file (: I don't think long-ish constants are a real problem since this functionality would very likely be written just a few times in autoloaders (as is typical in almost any project that would be interested in .phpc files in the first place) rather than repeatedly all over the place in every file (as with old-fashioned uses of 'require', and various templating situations). I will revise the RFC shortly. On Mon, Apr 9, 2012 at 1:51 PM, Luke Scott wrote: > On Apr 9, 2012, at 10:44 AM, Ralph Schindler w= rote: > >> Hey Tom, >> >> An idea, why not overload require/include with a second parameter that s= imply enforces an include mode. =A0For 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: >> >> =A0INCLUDE_MODE_PHP_START; >> =A0INCLUDE_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 =A0wrote: >>>> 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 =A0wrote: >>>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell =A0wrote: >>>>> >>>>>> It sounds like you are proposing to gradually kill the use of PHP fo= r >>>>>> 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 clearl= y >>>>> 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 ?> =A0(since PHP 5 due to how easy it is for whit= e >>>>> space to end up on the tail end of a file). this is even the case wit= h >>>>> 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 ?> =A0and 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 libra= ry >>>>>> 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 i= s >>>>> 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= /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 t= o >>>>>> help with the pollution problem. >>>>> >>>>> It's not as much as adding a keyword as it is what keyword you're add= ing. >>>>> >>>>> I hope the way I've explained things makes sense. >>>>> >>>>> Luke >>>>> >>>>>> >>>>>> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott =A0wrote: >>>>>>> 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 ofte= n >>>>>>> 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 ar= e >>>>>>> we talking about removing>>>>>> confusing to keep track of what is being talked about. If that is t= he >>>>>>> case, continue reading. >>>>>>> >>>>>>> I would prefer the starting>>>>>> Just explicitly forbid the ending ?> =A0tag and treat text before t= he >>>>>>> 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_templa= te >>>>>>> NOT require_code/require_file. Templates are the exception, not the >>>>>>> norm. >>>>>>> >>>>>>> Luke Scott >>>>>>> >>>>>>> On Apr 8, 2012, at 9:32 AM, Tom Boutell =A0wrote: >>>>>>> >>>>>>>> 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 s= ure >>>>>>>> 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 >> > > -- > 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