I think updating your RFC to cover the broad points that have changed is worth it, even if small differences will continue to be expressed about the syntax.
2012/4/16 Kris Craig <kris.cr...@gmail.com>: > > > 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 >> > -- 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
