Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59993 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70360 invoked from network); 16 Apr 2012 09:23:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Apr 2012 09:23:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=arvids.godjuks@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=arvids.godjuks@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender) X-PHP-List-Original-Sender: arvids.godjuks@gmail.com X-Host-Fingerprint: 209.85.161.170 mail-gx0-f170.google.com Received: from [209.85.161.170] ([209.85.161.170:63827] helo=mail-gx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 65/C0-05733-DF4EB8F4 for ; Mon, 16 Apr 2012 05:23:09 -0400 Received: by ggmb2 with SMTP id b2so2613754ggm.29 for ; Mon, 16 Apr 2012 02:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NhQqwFc1qH5PrtOoTHSmT3u+xAsrEUQwE/yH7H8sK90=; b=P2cCQcma0Yr5Xd3PVnbngHSSGh7FfyO2bncSPP85ZXJ2/D6ZyVygdFpcQ6iXK1k6WA r0nLhfDeKw9KDb5dQAqV4fEdfwcid0CIWCqWSO2KxCpDUyo2q56Mw8q1/WxDd13XwYA4 +0ljF/RrHFFt1ZoEWjy8LdaV4ZmQdqWpk9Q1yh15wPQU2P3VC9eMn1JVggpS+5/QUNyw EAgtd3E4s3EG6rUUnnQKlsjYl4db297nrfr/YCnbFmr22SH/fOINBeR6lJ2K/aCt1hMO uziHvvv2SfTCc7WnIcGbycaGSA2/RmVctGzqFKxZiIXHDqAsC/zX6Tc+y/LxakSRzrfk nZUQ== Received: by 10.50.46.138 with SMTP id v10mr4933714igm.18.1334568186888; Mon, 16 Apr 2012 02:23:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.134.233 with HTTP; Mon, 16 Apr 2012 02:22:41 -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> Date: Mon, 16 Apr 2012 12:22:41 +0300 Message-ID: To: Kris Craig Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=14dae9340b75b5400804bdc85ef0 Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts From: arvids.godjuks@gmail.com (Arvids Godjuks) --14dae9340b75b5400804bdc85ef0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I should say that I do not understand in full how it suppose to work. From the RFC it is absolutely unclear how to deal with this and the mixed code load approach is just dismissed as invalid concern, quoting from the RFC: > Besides, such an allowance is completely unnecessary anyway, since using non-horrible architecture can achieve the exact same result without having to pollute your .phpp stack. Here's a screenshot from a recent Internals thread where I illustrated this point a little more clearly: You just dismiss a valid stack structure with the screenshot below that and every PHP MVC framework I know of out there renders it's templates through a controller call or invoking a template engine of some kind in the main application and calling it's methods from controllers. Anyway the result is obvious - you have to make a global stand-alone template engine object that loads from index.php and not inside the application itself. I'm not willing to think how to couple them together and the difficulties with data passing, calling widgets and other stuff that comes along - it's just a stretch of epic proportions to radically alter the structure with unknown result in the end. So, since people write a lot about that RFC is not in sync with what you are writing, you should really update the thing. I follow the thread as much as I could, but lets be honest - following that wall of text posted every 4-5 minutes (while I read one mail the phone notified I received 2 more in the thread at times) was just not happening. So I'm convinced I skipped at least a half of the discussion just being humanly unable to read it all. The RFC should contain the solutions for the file template inclusion, 3rd party library inclusion,dealing with valid optimization practices and other related stuff. 16 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2012 =D0=B3. 11:09 =D0=BF=D0=BE=D0= =BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Kris Craig =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > > On Mon, Apr 16, 2012 at 12:57 AM, Arvids Godjuks > wrote: > >> 16 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2012 =D0=B3. 2:52 =D0=BF=D0=BE= =D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Kris Craig =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >> >> >>> >>> On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks < >>> arvids.godjuks@gmail.com> 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 (and 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 includes most= ly >>>> used core classes in one big file.that loads much faster and is used f= or >>>> production. Any other framework has user extentions or other type of >>>> solutions for this to speed up the application, and it makes really bi= g >>>> 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 less answe= rs >>>> there are. >>>> >>> >>> My response is in the other thread. But you're right, we should move >>> the discussion back here, so please post your reply here. Thanks! >>> >>> --Kris >>> >>> >> The Kris response from the "PHP-DEV Digest 13 Apr..." response to my mai= l >> quoted bellow: >> >> > I'm not quite sure I understand your concern. Are you saying that the >> Yii framework wouldn't work with this because .phpp files would be cache= d >> as .php?? If that's the case, what about .phpo? Or, perhaps we should >> name the extension .phpf instead, as in "PHP Framework-includable". >> >> What I'm saying that there is a widely used optimization technique - >> concatenate the project files in one big massive chunk, enable an opcode >> cache and things speed up big time. Almost any mid sized and above proje= ct >> ends up doing that in one or the other way. Some even do that on >> per-controller basis or otherwise - but the fact is - it's out there. >> I just gave an example of the popular framework that has this >> out-of-the-box as a feature. And I, for one, do not understand how this >> should play with your proposal, because in that state clean source code >> ends up with "tainted" source code in one big chunk of machine-generated >> striped-out-everything string of epic proportions witch PHP chews with >> happy face and damn fast (helps with response times a lot, up to the >> tenfold). >> > > What about the per-file approach that's been suggested? Would that work > with your framework? > > The stricter per-stack approach might wind up being better suited for > projects that are created from scratch with that architecture in mind. > It's common enough that I believe there's a genuine use case for it. If > we then had a separate per-file approach designed to accommodate > frameworks/libraries that by their nature might be a bit more tangled, I > think we could get the best of both worlds with this. > > --Kris > > --14dae9340b75b5400804bdc85ef0--