2012/4/16 Tom Boutell <t...@punkave.com> > 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. 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. 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 at the language level before proceeding with that. Specifically, is everybody good with using include/require as $bitwise_constant? Or do people still think the other options need to be debated more first? --Kris > > 2012/4/16 Kris Craig <kris.cr...@gmail.com>: > > > > > > 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 > > > > > > -- > 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 > >
