Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60033 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85752 invoked from network); 16 Apr 2012 23:11:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Apr 2012 23:11:00 -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.161.170 as permitted sender) X-PHP-List-Original-Sender: tom@punkave.com X-Host-Fingerprint: 209.85.161.170 mail-gx0-f170.google.com Received: from [209.85.161.170] ([209.85.161.170:59248] helo=mail-gx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 47/85-05733-407AC8F4 for ; Mon, 16 Apr 2012 19:11:00 -0400 Received: by ggmb2 with SMTP id b2so3173908ggm.29 for ; Mon, 16 Apr 2012 16:10:57 -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=fq/Gc5cYOD0Nhmfjj+kQmc4gJSGR6z0UzHbJR3GWx1w=; b=NP+ax/U42H0k1wcdF9ScZgPYBfDwdWfX9BknlODNIHYRA3vmIDedWVI7OpJ8JUKvQ7 a+QQh5v0IkhYTN7cciVPsEoP2HwPTK6wNWe6TQr4tmcItkU6c18Ky0CS3nfgnFYJZhu+ nB/jBg9wFJZvkknLmCVKu2B+KmlC3NCxVaaDRKfzCDKMVGtGg9bkl5Mofho9LLLrtT48 5jcjtxO1bOciuJOvi6sgvC8VzmlLEsV9of1g3aaVB7ujZAQyiMpoiPXkJLgFi5bPwOm2 L2i0iVZkVzyemRbv4UjNJpEWtWs+y8Y+vQoUarNyXt8izgvT+NHdLWopqcbAK/PzV1wN Z4LQ== MIME-Version: 1.0 Received: by 10.236.181.5 with SMTP id k5mr13234140yhm.61.1334617856856; Mon, 16 Apr 2012 16:10:56 -0700 (PDT) Received: by 10.101.57.14 with HTTP; Mon, 16 Apr 2012 16:10:56 -0700 (PDT) In-Reply-To: References: <4F876943.8030105@gmail.com> <4F877777.8050806@gmail.com> <4F8782CC.8030205@gmail.com> <4F87C9B0.4080809@gmail.com> <4F8AA9CF.6000003@gmail.com> <4CF91067-DBC4-4CD7-AF91-1814A6999EEF@punkave.com> Date: Mon, 16 Apr 2012 19:10:56 -0400 Message-ID: To: PHP Internals Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnsgJVuneQbXwTlQ22VB8OMgDUXzzISXnBhcOjdWjeI1inDuip/BZjIFfcXb7gq1WD2MNeg Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts From: tom@punkave.com (Tom Boutell) I think updating your RFC to cover the broad points that have changed is worth it, even if small differences will continue to be expressed about the syntax. 2012/4/16 Kris Craig : > > > 2012/4/16 Tom Boutell >> >> Kris, you have been talking recently about allowing for a mode that >> permits the inclusion of .php from .php... something (whatever we're >> calling this middle mode's recommended file extension). >> >> I think having three modes is overkill, but some people think having >> even two modes is overkill, so I'm prepared to live with having all >> three modes (traditional PHP, "pure" PHP that is allowed to include >> traditional PHP, and "purest" PHP that is not allowed to include >> traditional PHP). >> >> After all, I don't have to use "purest" mode if I choose not to do so >> - and I suspect most library authors won't because they want to write >> code that can include whatever the user wants it to. That's their >> choice and mine, and there's really no reason to deny you the option >> of "purest" mode. >> >> And one can make the argument that while, as you say, model code >> should never include a template, controller code (or classes in the >> view layer that manage templates) should invoke templates. That would >> give a better rationale for having all three types. >> >> However, your RFC still does not address allowing all three and >> currently includes very negative language about the middle option. > > > That's because I haven't updated it since the initial draft. > >> >> >> A second issue is that your RFC calls for file extensions to be >> explicitly recognized by PHP itself, which is something many people >> have objected to because the file extension may be unavailable or >> irrelevant depending on the environment. That's why my RFC addresses >> the file extension issue as a strongly recommended convention, not a >> language feature, and provides keywords that can be used to implement >> that convention (and really ought to provide options for the various >> SAPIs as well, so entry points can be pure PHP if desired). > > > That's not actually true.=9A What it's referring to is a convention and > distinguishing between file extensions when accessed via the webserver. > This is already the current behavior via handlers; the RFC isn't actually > proposing to parse the filename itself at the langugage level.=9A Though > seeing as how you're the second person to have misinterpreted it to mean > that, it's possible that the wording I used wasn't clear enough on that > point. > >> >> >> I think it's probably time to write an updated version of your RFC so >> we can figure out if we're developing common ground here. > > > I was hoping to get a little more clarification on the inclusion method a= t > the language level before proceeding with that.=9A Specifically, is every= body > good with using include/require as $bitwise_constant?=9A Or do people sti= ll > think the other options need to be debated more first? > > --Kris > >> >> >> 2012/4/16 Kris Craig : >> > >> > >> > 2012/4/16 Tom Boutell >> >> >> >> Also, Kris's proposal requires that an additional flag be tracked all >> >> the way down through the stack of requires and includes from the poin= t >> >> where pure mode is first encountered, remembering that we're in pure >> >> mode. Note that this flag cannot be a global variable because .php >> >> files that were loaded before this .phpp file are still permitted to >> >> load things, including when acting as autoloaders on behalf of .phpp >> >> code... my head hurts. This cannot be the cleanest way to solve the >> >> problem. >> >> >> >> 2012/4/16 Tom Boutell : >> >> > Oh I see. Yes, this is one of the reasons I don't like the "pure >> >> > can't >> >> > include non-pure" idea. >> >> > >> >> > Another reason: you can't write generic algorithms. PHP 5.4 has muc= h >> >> > improved support for anonymous functions, so we should see an >> >> > increase >> >> > in libraries that take a few functions as parameters and carry out = an >> >> > operation via those functions. But what if one of those functions >> >> > requires something from a .php file? Whoops, I guess it's not a >> >> > generic sorting algorithm library I just released, it's a "generic >> >> > sorting as long as none of your functions touch a .php file" >> >> > algorithm >> >> > library. And good luck figuring this out when it happens. >> >> > >> >> > Kris has pointed out that you could still load a .php file via a >> >> > function that was defined earlier in a .php file that later include= s >> >> > .phpp. But this just means that, like my RFC, his RFC contains a >> >> > compromise about strictness. It's just that his compromise is more >> >> > confusing and less likely to be understood before the user gets >> >> > frustrated and declares the whole thing not worth messing with. I >> >> > think ".phpp files don't contain but can require and >> >> > include files that do" is a much clearer compromise, one that will >> >> > get >> >> > us what we want (an ever increasing percentage of .phpp files) >> >> > without >> >> > making enemies and generating opposition along the way to that bett= er >> >> > place. >> >> > >> >> > On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks >> >> > wrote: >> >> >> 16 =C1=D0=D2=C5=CC=D1 2012=9A=C7. 16:09 =D0=CF=CC=D8=DA=CF=D7=C1= =D4=C5=CC=D8 Tom Boutell >> >> >> =CE=C1=D0=C9=D3=C1=CC: >> >> >> >> >> >>> These tools already strip > >> >>> changes >> >> >>> to >> >> >>> support rolling in a .phpp file unmodified. Unless I am missing >> >> >>> something? >> >> >>> >> >> >>> Sent from my iPhone >> >> >>> >> >> >>> On Apr 15, 2012, at 5:30 PM, Arvids Godjuks >> >> >>> >> >> >>> wrote: >> >> >>> >> >> >>> > I posted the bellow text in other thread, but i should have it >> >> >>> > post >> >> >>> > here, >> >> >>> > so i'm reposting it to this thread. >> >> >>> > >> >> >>> > Well, it's time for me to remind about the techique many use (a= nd >> >> >>> > some >> >> >>> > frameworks provide it out of the box) - the application file >> >> >>> > concatination >> >> >>> > to speed up file loading. >> >> >>> > Yii framework provides a Yiilite.php file for this, that includ= es >> >> >>> > mostly >> >> >>> > used core classes in one big file.that loads much faster and is >> >> >>> > used >> >> >>> > for >> >> >>> > production. Any other framework has user extentions or other ty= pe >> >> >>> > of >> >> >>> > solutions for this to speed up the application, and it makes >> >> >>> > really >> >> >>> > big >> >> >>> > difference. >> >> >>> > So there is a good question - how the hell in a MVC framework >> >> >>> > would >> >> >>> > i >> >> >>> > combine my models, controllers, components and other stuff that >> >> >>> > will >> >> >>> > definetly be as in .php so in .pphp. And not every file will be >> >> >>> > cached >> >> >>> > like >> >> >>> > that - some will remain as distinct files even in production. >> >> >>> > >> >> >>> > The further discussion goes the more questions there is and les= s >> >> >>> > answers >> >> >>> > there are. >> >> >> >> >> >> >> >> >> Yes they obviously do, but that's not what I'm concerned about. >> >> >> What I'm concerned is that code from .php and .pphp files get's >> >> >> mixed >> >> >> in >> >> >> together - template engine related stuff is used as much, as do >> >> >> controllers, >> >> >> session handling classes and bunch of other stuff that by definiti= on >> >> >> is >> >> >> .pphp stuff, but the template stuff is .php and it includes >> >> >> templates. >> >> >> So >> >> >> basically everything just has to fall back to the embedded PHP mod= e >> >> >> to >> >> >> work >> >> >> and we have no gain from the proposal what so ever - it just becom= es >> >> >> useless. >> >> >> >> >> >> That's not counting other issues that people and I have been voici= ng >> >> >> and to >> >> >> be honest, I never saw a reply to any of it. Maybe there is a repl= y >> >> >> to >> >> >> all=9Athose=9Aquestions, but they are under wall of text that usua= lly >> >> >> goes >> >> >> in >> >> >> reply - that just discourages to read it at all. >> >> > >> >> > >> >> > >> >> > -- >> >> > Tom Boutell >> >> > P'unk Avenue >> >> > 215 755 1330 >> >> > punkave.com >> >> > window.punkave.com >> >> >> >> >> >> >> >> -- >> >> 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 >> >> >> > >> > The RFC is vague on these points because they haven't been determined >> > yet, >> > though I am starting to lean toward the include/require parameter opti= on >> > for >> > includes. >> > >> > To Tom's point, these questions have already been addressed.=9A Basica= lly, >> > there will be a third type that's on a per-file basis, designed to >> > mitigate >> > the concerns that have been expressed over making this accessible to >> > people >> > using certain frameworks that utilize tangled architecture.=9A The >> > per-stack >> > option will be more suitable for applications that have been designed >> > from >> > the ground-up to use a seperated architecture.=9A Though the per-file = one >> > really wouldn't be useful for me, enough people believe that it will >> > be.=9A So >> > since there are valid use cases for both options, I'll include them >> > both. >> > >> > Please refer to my post on Pierre's thread.=9A I outlined an idea for = how >> > this >> > could work syntactically.=9A Please post your responses here though so= the >> > thread will be easier to follow. >> > >> > --Kris >> > >> >> >> >> -- >> 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