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 апреля 2012 г. 11:09 пользователь Kris Craig <kris.cr...@gmail.com>написал: > > > On Mon, Apr 16, 2012 at 12:57 AM, Arvids Godjuks <arvids.godj...@gmail.com > > wrote: > >> 16 апреля 2012 г. 2:52 пользователь Kris Craig <kris.cr...@gmail.com>написал: >> >> >>> >>> On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks < >>> arvids.godj...@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 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 type 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 less answers >>>> 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 mail >> 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 cached >> 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 project >> 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 > >
