Re: [RFC] New .phpp File Type for Pure-Code PHP Scripts

On Mon, Apr 16, 2012 at 12:57 AM, Arvids Godjuks <arvids.godjuks@gmail.com>wrote: > 16 апреля 2012 г. 2:52 пользователь Kris Craig > <kris.craig@gmail.com>написал: > > >> >> 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 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