2012/4/16 Tom Boutell <t...@punkave.com> > Also, Kris's proposal requires that an additional flag be tracked all > the way down through the stack of requires and includes from the point > 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 <t...@punkave.com>: > > 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 much > > 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 includes > > .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 <?php and ?> 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 better > > place. > > > > On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks > > <arvids.godj...@gmail.com> wrote: > >> 16 апреля 2012 г. 16:09 пользователь Tom Boutell <t...@punkave.com> > написал: > >> > >>> These tools already strip <?php tags, they would need minimal 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 <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. > >> > >> > >> 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 definition 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 mode to > work > >> and we have no gain from the proposal what so ever - it just becomes > >> useless. > >> > >> That's not counting other issues that people and I have been voicing > and to > >> be honest, I never saw a reply to any of it. Maybe there is a reply to > >> all those questions, but they are under wall of text that usually 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 option for includes.
To Tom's point, these questions have already been addressed. Basically, 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. The per-stack option will be more suitable for applications that have been designed from the ground-up to use a seperated architecture. Though the per-file one really wouldn't be useful for me, enough people believe that it will be. So since there are valid use cases for both options, I'll include them both. Please refer to my post on Pierre's thread. I outlined an idea for how this could work syntactically. Please post your responses here though so the thread will be easier to follow. --Kris
