Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
16 апреля 2012 г. 2:52 пользователь Kris Craig kris.cr...@gmail.comнаписал: On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks arvids.godj...@gmail.comwrote: 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).
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Mon, Apr 16, 2012 at 12:57 AM, Arvids Godjuks arvids.godj...@gmail.comwrote: 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
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
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
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
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.
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
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
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
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
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
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. 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). 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. 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
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
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
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
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
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
@Ferenc Thanks for the thoughtful analysis! I must confess I'm a bit groggy at the moment so I'll have to go over it later. sure, take your time. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On 14/04/12 03:41, Kris Craig wrote: On Thu, Apr 12, 2012 at 11:37 PM, David Muir davidkm...@gmail.com mailto:davidkm...@gmail.com wrote: On 13/04/12 15:13, Kris Craig wrote: Again, the controller should NOT be a .phpp file. Likewise, your model should NOT be hooking directly to the view. The controller hooks to the model. The controller then sanitizes that and returns it to the view. Alternatively, if you're not conforming to a pure MVC standard, the controller can also hook to a regular .php file in the model and pass the data to that. Either way, it all passes through the controller. The model and view should never be interacting directly. MVC or not, that's just bad architecture and there are zero advantages to using such an ad hoc approach. If a developer insists on using such a broken model, however, they're more MVC is a broken model/bad architecture? Arrooo? Not sure where you got /that/ from, as it's basically the exact opposite of what I said That was me being snarky. I understood what you were trying to say, but you were trumpeting the superiority of MVC, while deriding architecture that conforms to common MVC patterns. than welcome to! That's what people love (and hate) about PHP. It's flexible. They just won't be able to use a .phpp file upstream from that, as it is by its very nature inherently incompatible with such a broken model. The only way to force it to be compatible would be to make the .phpp file essentially meaningless. So if you're writing good code structure, a .phpp file will help you make it even better. If you're writing bad architecture, then just keep doing what you're already doing and don't worry about using a .phpp file! This will in no way stop you from being able to do what you can already do in PHP. You're just insisting on wanting to use a pure code file for something that it's not intended to be used for. Just like having object orientation added in PHP 5 didn't stop you from writing procedural code if you want to, introducing this in PHP 6 won't stop you from writing disorganized code if you still want to. What this will do is provide a valuable option for people who do feel that writing clean, role-segregated code is important. So basically, the only parts that might be ok to write as .phpp are some model and utility classes? Essentially, yes. Despite your implication, often times these components make up the vast majority of a modern PHP application. It's also the portion that is typically not provided by frameworks and libraries. If you're extending or implementing anything from those libraries, and they're provided as .php (as most things would be), then you won't be able to use them in your .phpp classes (unless you explicitly include them from a .php file further up the chain). You end up losing a lot of flexibility, with no perceivable gain. Cheers, David
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Sun, Apr 15, 2012 at 3:58 AM, David Muir davidkm...@gmail.com wrote: On 14/04/12 03:41, Kris Craig wrote: On Thu, Apr 12, 2012 at 11:37 PM, David Muir davidkm...@gmail.com wrote: On 13/04/12 15:13, Kris Craig wrote: Again, the controller should NOT be a .phpp file. Likewise, your model should NOT be hooking directly to the view. The controller hooks to the model. The controller then sanitizes that and returns it to the view. Alternatively, if you're not conforming to a pure MVC standard, the controller can also hook to a regular .php file in the model and pass the data to that. Either way, it all passes through the controller. The model and view should never be interacting directly. MVC or not, that's just bad architecture and there are zero advantages to using such an ad hoc approach. If a developer insists on using such a broken model, however, they're more MVC is a broken model/bad architecture? Arrooo? Not sure where you got *that* from, as it's basically the exact opposite of what I said That was me being snarky. I understood what you were trying to say, but you were trumpeting the superiority of MVC, while deriding architecture that conforms to common MVC patterns. than welcome to! That's what people love (and hate) about PHP. It's flexible. They just won't be able to use a .phpp file upstream from that, as it is by its very nature inherently incompatible with such a broken model. The only way to force it to be compatible would be to make the .phpp file essentially meaningless. So if you're writing good code structure, a .phpp file will help you make it even better. If you're writing bad architecture, then just keep doing what you're already doing and don't worry about using a .phpp file! This will in no way stop you from being able to do what you can already do in PHP. You're just insisting on wanting to use a pure code file for something that it's not intended to be used for. Just like having object orientation added in PHP 5 didn't stop you from writing procedural code if you want to, introducing this in PHP 6 won't stop you from writing disorganized code if you still want to. What this will do is provide a valuable option for people who do feel that writing clean, role-segregated code is important. So basically, the only parts that might be ok to write as .phpp are some model and utility classes? Essentially, yes. Despite your implication, often times these components make up the vast majority of a modern PHP application. It's also the portion that is typically not provided by frameworks and libraries. If you're extending or implementing anything from those libraries, and they're provided as .php (as most things would be), then you won't be able to use them in your .phpp classes (unless you explicitly include them from a .php file further up the chain). You end up losing a lot of flexibility, with no perceivable gain. The gain has been described by myself and others quite a bit already. As far as I can tell, the fact that some frameworks/libraries wouldn't be compatible with this doesn't negate the unrelated advantages that do exist. Worst-case scenario, you just wouldn't use this with those frameworks. But again, before we jump down that rabbit hole again, please refer to recent suggestions that have been made regarding that; i.e. a third type for per-file instead of per-stack checking. While I see no more value in per-file checking than you do in per-stack, it would alleviate your concerns regarding certain frameworks and libraries. --Kris Cheers, David
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
The gain has been described by myself and others quite a bit already. As far as I can tell, the fact that some frameworks/libraries wouldn't be compatible with this doesn't negate the unrelated advantages that do exist. Worst-case scenario, you just wouldn't use this with those frameworks. usually we tend to accept changes only if the pros remarkably overweight the cons. introducing a new language construct which target audience is just a small percentage of the potential userbase seems to have a hard time getting accepted. (annotations was an example of this, even thought that the syntax was thought out, and it was/is already used in the wild (Doctrine2, Symfony2) the majority of the voters seemed to be against it) of course you can succeed where others failed, but I think it would greatly increase the chances if: 1, the intention of the change is clearly laid out, and easily understood via reading the RFC 2, the change would make some useful real-life scenario possible or significantly easier 3, the change would make the least impact on the pre-existing code(minimal required BC impact) 4, the change is in line with the PHP way. I think that the current proposals are lacking in those aspects. but to go back to your proposal: I think that it would be nice, if you could update the RFC based on the discussion, as it will be harder and harder to join the discussion, if one has to read the RFC then read all of the related discussion (scattered through many threads) in the correct order to be able to catch up with the current status. you mentioned that some ideas or alternatives was presented but you didn't wanted to incorporate those, until you finish sorting those out in the mailing list and consensus is reached. which is a good idea at first, but if/when the discussion is abadoned/derailed/etc. then there it is a good chance, that the original idea is lost too. I really liked the https://wiki.php.net/rfc/closures/object-extension in this regard (even though that in the end that was also abandoned so it isn't consistent with the actual implementation). It describes the ideas which were presented, compares the pros/cons, etc. I really liked that. So I would suggest you to update you RFC accordingly (and while I think that the separate nophptags RFCs should be kept separate, but mentioning what deviates yours from the other two could be a good idea too). Over the years, people have occasionally called for one of a few fundamental changes would be nice if you could link those calls if you have them, maybe they have some arguments that we didn't see yet (or maybe we could see that some of those are PEBKAC) There will be no BC breaks. depending on the implementation (making the SAPIs aware of the new file extension or the parser to the new ?phpsomething tag) there is a small chance that somebody already using that extension/tag which would turn those files executable php scripts. ofc. it isn't that likely. of course if we go with the ?phpsomething tag, then the many of the current premises needs to be rewritten, and it would remove the I can save 5 keystrokes per files and some random output by mistake before the opening tag sending out junk before the opening tag from the equitation. you still need to have an opening tag, and you can also put something before the tag (albeit I think that those problems would error out with ?phpo either because the ?phpo could be only at the begining of the file, or by an unexpected direct output in case of another phpp file including the borked file), so what we have left is the ability to create an arbitrary restriction so that phpp files cannot switch to template mode or include files(directly or indirectly) which would do that. As others (and your RFC) stated, this would only cover part of the original issue: class files spitting out direct input. Your solution would only solve half of the problem, but in exchange you would make the promise that under no circumstances would you try to include any php file from your phpp file. Which can be a really hard thing to promise upfront: - if you have file includes based on some dynamic logic(the filename coming from database for example). - if you have a global autoloader, that can cause hard-to-see dependencies. - if you have an error/exception handler, that can cause hard-to-see dependencies. I think it would make more sense, if we would solve the original problem: preventing the the class files from spitting out output. one could do something similar via ob_start-ing before the file include and discarding the buffer or erroring out if the buffer isn't empy (albeit that would only prevent the mistakes, not the malicious code from flushing the buffer). another possibility would be adding control options for the include/require calls, so one can tell whether the included files can have output (or allowing a variable to be passed, which will hold the generated output, that would be really nice, as many of the php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
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.
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks arvids.godj...@gmail.comwrote: 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
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Sun, Apr 15, 2012 at 2:21 PM, Ferenc Kovacs tyr...@gmail.com wrote: The gain has been described by myself and others quite a bit already. As far as I can tell, the fact that some frameworks/libraries wouldn't be compatible with this doesn't negate the unrelated advantages that do exist. Worst-case scenario, you just wouldn't use this with those frameworks. usually we tend to accept changes only if the pros remarkably overweight the cons. introducing a new language construct which target audience is just a small percentage of the potential userbase seems to have a hard time getting accepted. (annotations was an example of this, even thought that the syntax was thought out, and it was/is already used in the wild (Doctrine2, Symfony2) the majority of the voters seemed to be against it) of course you can succeed where others failed, but I think it would greatly increase the chances if: 1, the intention of the change is clearly laid out, and easily understood via reading the RFC 2, the change would make some useful real-life scenario possible or significantly easier 3, the change would make the least impact on the pre-existing code(minimal required BC impact) 4, the change is in line with the PHP way. I think that the current proposals are lacking in those aspects. but to go back to your proposal: I think that it would be nice, if you could update the RFC based on the discussion, as it will be harder and harder to join the discussion, if one has to read the RFC then read all of the related discussion (scattered through many threads) in the correct order to be able to catch up with the current status. you mentioned that some ideas or alternatives was presented but you didn't wanted to incorporate those, until you finish sorting those out in the mailing list and consensus is reached. which is a good idea at first, but if/when the discussion is abadoned/derailed/etc. then there it is a good chance, that the original idea is lost too. I really liked the https://wiki.php.net/rfc/closures/object-extension in this regard (even though that in the end that was also abandoned so it isn't consistent with the actual implementation). It describes the ideas which were presented, compares the pros/cons, etc. I really liked that. So I would suggest you to update you RFC accordingly (and while I think that the separate nophptags RFCs should be kept separate, but mentioning what deviates yours from the other two could be a good idea too). Over the years, people have occasionally called for one of a few fundamental changes would be nice if you could link those calls if you have them, maybe they have some arguments that we didn't see yet (or maybe we could see that some of those are PEBKAC) There will be no BC breaks. depending on the implementation (making the SAPIs aware of the new file extension or the parser to the new ?phpsomething tag) there is a small chance that somebody already using that extension/tag which would turn those files executable php scripts. ofc. it isn't that likely. of course if we go with the ?phpsomething tag, then the many of the current premises needs to be rewritten, and it would remove the I can save 5 keystrokes per files and some random output by mistake before the opening tag sending out junk before the opening tag from the equitation. you still need to have an opening tag, and you can also put something before the tag (albeit I think that those problems would error out with ?phpo either because the ?phpo could be only at the begining of the file, or by an unexpected direct output in case of another phpp file including the borked file), so what we have left is the ability to create an arbitrary restriction so that phpp files cannot switch to template mode or include files(directly or indirectly) which would do that. As others (and your RFC) stated, this would only cover part of the original issue: class files spitting out direct input. Your solution would only solve half of the problem, but in exchange you would make the promise that under no circumstances would you try to include any php file from your phpp file. Which can be a really hard thing to promise upfront: - if you have file includes based on some dynamic logic(the filename coming from database for example). - if you have a global autoloader, that can cause hard-to-see dependencies. - if you have an error/exception handler, that can cause hard-to-see dependencies. I think it would make more sense, if we would solve the original problem: preventing the the class files from spitting out output. one could do something similar via ob_start-ing before the file include and discarding the buffer or erroring out if the buffer isn't empy (albeit that would only prevent the mistakes, not the malicious code from flushing the buffer). another possibility would be adding control options for the include/require calls, so one can tell whether the
RE: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
Sent: Friday, April 13, 2012 3:39 PM On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw johncrens...@priacta.com wrote: On top of this, there's an argument that you're not addressing: most template engines in PHP either directly consume PHP template files... or compile templates into... PHP template files. As such, sooner or later, you'll have a class that includes a PHP template file, and that's where things break for me in this proposal. They don't break because nobody in their right mind would ever try to include a .phpp file in a framework like that. If its stack is so entangled, the very notion of a pure PHP stack is just incompatible. So your best bet on a framework like that would be to stick with .php. Um, so if you aren't using any form of template engine whatsoever, what are you proposing? You're saying we should all go back to the good ol' C days of trying to put together valid markup using string concatenation? (Or worse, manipulation of DOM classes?) No thanks. IMO this is a bit like blowing up London to stop a jaywalker. That's a logical fallacy; i.e. your contention relies on the premise that, if this doesn't work with every single framework known to exist, then it doesn't work with any template engine whatsoever. That's just patently ridiculous and could not be further from the truth. I think you missed the problem entirely. All but a tiny handful of template engines (and ALL of the template engines that are fast and powerful enough to use as the view component for a site) compile into PHP templates. Once something is included in the way you propose there is no longer ANY viable view option. The only way to output anything at that point is with strings and echos. The entire reason PHP became popular in the first place is because it was a first class template language. Web development is, at the end of the day, metaprogramming. After a lot of thought I've decided that I'm strongly opposed to the nature of this proposal at a fundamental level. It isn't that I just wouldn't use it. This proposal is inherently destructive to the PHP development community. This effectively attempts to split PHP into two languages. Current PHP isn't really compatible with the proposed .phpp version of PHP, in the sense that you can't safely use both in the same code base. Unfortunately this will not be clear to anybody at first, which will lead to mass proliferation of .phpp libraries which are like poison to any unsuspecting PHP user foolish enough to try to use one. This isn't just a BC thing, it is really a permanent language fork. A few points: 1. How exactly will this single-handedly destroy the PHP community? I will give you bonus points for creative hyperbole, though. That's not what I said. I said it is inherently destructive to the PHP development community. I stand by that. It segregates the community and effectively divides PHP into two languages that both seem (on the surface) to be the same thing. Problem is they're not really compatible. If they are used together one will eventually cause the other to break in confusing ways. In this thread we've had people suggest that library developers should use this .phpp stuff. That's EXACTLY the problem I'm worried about. All it takes is one callback, one event, one autoloader, one error handler, one anything, and the entire application system falls apart because one library decided that it didn't need template mode. If the division were clear it wouldn't even be so bad, but it's not clear. Everything is called PHP, and this is getting marketed as just use the .phpp extension if your file doesn't use templating. It is devilishly subtle, and the average library developer who decides to do this won't realize at all the hell that they are about to release on the web developers who use their library, because if their library is in the call stack at all, for any reason, any attempt at templating will die. 2. This does NOT split PHP into two languages. In fact, there are no changes to the language in this RFC. The only difference is a new file type that parses PHP without the need for a ?php tag and with ? raw HTML code not being permitted within that file type's stack. Again, bonus points for wild hyperbole Yeah, you missed it, which ironically is exactly my concern. I refer you to two paragraphs earlier. You've said before that no sane developer would include .phpp files somewhere that doesn't have a rigidly defined inclusion and operation structure. This is exactly the problem. Most MVC frameworks now heavily use autoloaders and other patterns (plugins, listeners, error handlers, etc.) that do NOT have a rigid inclusion structure. And that's all OK (wonderful in fact, it allows for incredible things). This syntax change though forces a division in the community with these MVC
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
John Crenshaw wrote: I think that covered just about everything quite tidily John. Certainly a lot more succinct than I would have managed! Well put ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Sat, Apr 14, 2012 at 11:29 AM, John Crenshaw johncrens...@priacta.comwrote: Sent: Friday, April 13, 2012 3:39 PM On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw johncrens...@priacta.com wrote: On top of this, there's an argument that you're not addressing: most template engines in PHP either directly consume PHP template files... or compile templates into... PHP template files. As such, sooner or later, you'll have a class that includes a PHP template file, and that's where things break for me in this proposal. They don't break because nobody in their right mind would ever try to include a .phpp file in a framework like that. If its stack is so entangled, the very notion of a pure PHP stack is just incompatible. So your best bet on a framework like that would be to stick with .php. Um, so if you aren't using any form of template engine whatsoever, what are you proposing? You're saying we should all go back to the good ol' C days of trying to put together valid markup using string concatenation? (Or worse, manipulation of DOM classes?) No thanks. IMO this is a bit like blowing up London to stop a jaywalker. That's a logical fallacy; i.e. your contention relies on the premise that, if this doesn't work with every single framework known to exist, then it doesn't work with any template engine whatsoever. That's just patently ridiculous and could not be further from the truth. I think you missed the problem entirely. All but a tiny handful of template engines (and ALL of the template engines that are fast and powerful enough to use as the view component for a site) compile into PHP templates. Once something is included in the way you propose there is no longer ANY viable view option. The only way to output anything at that point is with strings and echos. The entire reason PHP became popular in the first place is because it was a first class template language. Web development is, at the end of the day, metaprogramming. As I said, this is NOT an inherent conflict. What it comes down to is *how* this compilation, as you put it, is taking place. After a lot of thought I've decided that I'm strongly opposed to the nature of this proposal at a fundamental level. It isn't that I just wouldn't use it. This proposal is inherently destructive to the PHP development community. This effectively attempts to split PHP into two languages. Current PHP isn't really compatible with the proposed .phpp version of PHP, in the sense that you can't safely use both in the same code base. Unfortunately this will not be clear to anybody at first, which will lead to mass proliferation of .phpp libraries which are like poison to any unsuspecting PHP user foolish enough to try to use one. This isn't just a BC thing, it is really a permanent language fork. A few points: 1. How exactly will this single-handedly destroy the PHP community? I will give you bonus points for creative hyperbole, though. That's not what I said. I said it is inherently destructive to the PHP development community. I stand by that. It segregates the community and effectively divides PHP into two languages that both seem (on the surface) to be the same thing. Problem is they're not really compatible. If they are used together one will eventually cause the other to break in confusing ways. No, it doesn't. I've already explained how your claim that it creates 2 languages is inaccurate. Simply repeating a false claim won't make it any more true. That, too, is a logical fallacy. Also, if you claim that something is inherently destructive to the PHP development community, you're essentially saying that it will single-handedly destroy the PHP community, which is an utterly ridiculous statement no matter how you look at it. That's what I mean when I refer to cheap scare tactics. In this thread we've had people suggest that library developers should use this .phpp stuff. That's EXACTLY the problem I'm worried about. All it takes is one callback, one event, one autoloader, one error handler, one anything, and the entire application system falls apart because one library decided that it didn't need template mode. And? That same argument could be made to argue that the header() function should be eliminated. As we've seen in the separate threads about LFI, the developer has to take some responsibility for not writing bad code. The problem you mention is *easily *avoidable. If you're mixing your autoloaders/handlers/etc in such an ad hoc fashion, then using that with .phpp would not be a good idea. Also, I've repeatedly offered a third solution that would alleviate concerns raised about these specific cases, but you two have yet to even acknowledge it, let alone respond to it. That suggests, to me at least, that you're more concerned with just shooting this down on any grounds you can
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Thu, Apr 12, 2012 at 11:13 PM, Kris Craig kris.cr...@gmail.com wrote:
On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur john.lesu...@gmail.comwrote:
On Thu, Apr 12, 2012 at 9:00 PM, Kris Craig kris.cr...@gmail.com wrote:
On Thu, Apr 12, 2012 at 7:51 PM, John LeSueur john.lesu...@gmail.comwrote:
On Thu, Apr 12, 2012 at 7:49 PM, Kris Craig kris.cr...@gmail.comwrote:
On Thu, Apr 12, 2012 at 6:35 PM, David Muir davidkm...@gmail.com
wrote:
On 13/04/12 11:03, Kris Craig wrote:
On Thu, Apr 12, 2012 at 5:46 PM, David Muir davidkm...@gmail.com
wrote:
On 13/04/12 10:04, Kris Craig wrote:
On Thu, Apr 12, 2012 at 4:46 PM, David Muir davidkm...@gmail.com
wrote:
On 13/04/12 09:38, Yasuo Ohgaki wrote:
Hi,
2012/4/13 Kris Craig kris.cr...@gmail.com:
Per recent discussions, I have drafted an RFC for this. This
proposal
offers what I believe to be a more sane and realistic approach
to
addressing the question of incorporating a new breed of
tag-less PHP
scripts.
https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.
CLI may use .phpp as PHP script always. (i.e. execute w/o ?php
or
else)
It's like DOS, though.
How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to
locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?
A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR
will be
thrown for require; in both instances, the included file will be
ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
That's a huge WTF that a templating library can't be written as
.phpp,
because it then won't be able to load a template.
That's actually not true. Please refer to the diagram embedded in
the
RFC.
Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway.
The
.phpp file is, at least for the most part, intended to be included
from a
regular .php file, which also would include whatever you're using
for your
templates. In other words, they can interact just fine; you just
can't put
the template upstream from a .phpp file in the include stack--
which,
again, you really shouldn't be doing, anyway, as it's just bad
architecture.
How is this bad architecture? Every framework I've seen that has
some
kind of templating layer that handles the scope and inclusion of the
template, and it happens further down the chain from the
controlling code.
Zend_View, Twig or Smarty would have to remain as .php and not
.phpp,
otherwise they wouldn't be able to render the templates.
In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers,
and some
services would have to remain as .php so that templates could be
executed.
Oh, and the autoloader can't be .phpp either. But then if it's
.php, then
the autoloader can't be called from .phpp files to include .php
files.
Cheers,
David
It's been awhile since I've used Smarty, but unless my memory is
failing
me, I'm pretty sure it's not restricted to being several points
removed
upstream as you described. I'm not familiar with Zend_View or Twig
so I
can't comment on those.
Thing is, there's no reason why you can't hook any framework into
this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on
top of
it, then use that same controller class to interface with the .phpp
stack.
Problem solved. It's really not as complicated or confusing as
you're
making it out to be.
--Kris
Both Smarty and Twig compile your template files down to php
templates.
Zend_View, Aura.View, and Symfony's php view include php files
directly
without a compilation phase.
I don't get how I would write a simple controller class layer to
operate
on top of it.
Does the inclusion limitation apply to just the script in question,
or the
entire call stack?
A simplified example:
index.php - FrontController.phpp - Controller.phpp - View.phpp -
can't
include template.phtml
index.php - FrontController.phpp - Controller.phpp - View.php -
can
include template.phtml ?
But I can't do require_once('View.php') in the controller.
If there's an autoloader involved, it would have to be set up in
index.php, and would also have to be .php so that it can include
both file
types.
index.php -
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On 2012-04-13, Kris Craig kris.cr...@gmail.com wrote:
On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur john.lesu...@gmail.com wrote:
//a controller, maybe a class, maybe just a set of functions, but in a
.phpp file
function getLoginPage()
{
//set up some data
//some people like to use plain .php for templates
include 'templates/loginPage.php';
//other people like to use a View library
$view-render('loginPage.tpl');
}
In the case of using a view object, your controller can be a .phpp file.
In the case of the include, it cannot. Now consider the case of the
implementation of the render() method:
function render($template)
{
$compiledTemplate = $this-compile($template);
include $compiledTemplate;
}
Now your render method cannot be in a .phpp file.
Again, the controller should NOT be a .phpp file. Likewise, your model
should NOT be hooking directly to the view. The controller hooks to the
model. The controller then sanitizes that and returns it to the view.
Alternatively, if you're not conforming to a pure MVC standard,
Sorry, this is where you lose me. There's no pure MVC standard,
particularly when it comes to MVC implementation on the web. There are
many, many, many interpretations of how MVC works, and some generally
accepted understanding around separation of concerns, but if you look at
the ecosystem of MVC frameworks in PHP alone, you'll see that none of
the frameworks do things the same way.
On top of this, there's an argument that you're not addressing: most
template engines in PHP either directly consume PHP template files...
or compile templates into... PHP template files. As such, sooner or
later, you'll have a class that includes a PHP template file, and that's
where things break for me in this proposal.
I think the pure PHP vs embedded PHP has to be determined in a
file-by-file basis, if at all -- NOT based on whether or not a file is
consuming a file that has embedded PHP. Once you go down that rabbit
hole, as soon as you have one file with embedded PHP (and most likely,
you will), you'll have to assume the entire project is. At that point,
there's zero benefit at all to making a distinction.
The proposals to use a flag with include, or to provide a separate
script() function for switching between pure PHP/embedded PHP make
sense to me. These make it easy for a framework/project to provide
autoloaders that choose the appropriate flag/function necessary to load
the class, and to select the appropriate flag/function when including
embedded artifacts. They also make auditing code easy -- you can grep
for one or the other.
File extensions, on the other hand, are a non-starter, as is any
approach that would insist that any consumer of a script that uses
embedding be marked as embedded as well.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Thu, Apr 12, 2012 at 11:37 PM, David Muir davidkm...@gmail.com wrote: On 13/04/12 15:13, Kris Craig wrote: Again, the controller should NOT be a .phpp file. Likewise, your model should NOT be hooking directly to the view. The controller hooks to the model. The controller then sanitizes that and returns it to the view. Alternatively, if you're not conforming to a pure MVC standard, the controller can also hook to a regular .php file in the model and pass the data to that. Either way, it all passes through the controller. The model and view should never be interacting directly. MVC or not, that's just bad architecture and there are zero advantages to using such an ad hoc approach. If a developer insists on using such a broken model, however, they're more MVC is a broken model/bad architecture? Arrooo? Not sure where you got *that* from, as it's basically the exact opposite of what I said than welcome to! That's what people love (and hate) about PHP. It's flexible. They just won't be able to use a .phpp file upstream from that, as it is by its very nature inherently incompatible with such a broken model. The only way to force it to be compatible would be to make the .phpp file essentially meaningless. So if you're writing good code structure, a .phpp file will help you make it even better. If you're writing bad architecture, then just keep doing what you're already doing and don't worry about using a .phpp file! This will in no way stop you from being able to do what you can already do in PHP. You're just insisting on wanting to use a pure code file for something that it's not intended to be used for. Just like having object orientation added in PHP 5 didn't stop you from writing procedural code if you want to, introducing this in PHP 6 won't stop you from writing disorganized code if you still want to. What this will do is provide a valuable option for people who do feel that writing clean, role-segregated code is important. So basically, the only parts that might be ok to write as .phpp are some model and utility classes? Essentially, yes. Despite your implication, often times these components make up the vast majority of a modern PHP application. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Fri, Apr 13, 2012 at 1:00 AM, Arvids Godjuks arvids.godj...@gmail.comwrote: Kris. I can give you a real world example where that straight MVC with the. pphp if not breaks, then definetly becomes an ugly mess. I use Yii framework as my tool, it has some very nice tools for templating like widgets. Widgets provide a container to put functionalit required by multiple pages and it contains a controller like code and a template. It can and most times will use models and other library stuff to do its work. And all that code is loaded via an autoloader (only templates are loaded localy in a controller method). As i see it, i will spend a lot of time figuring out if i need to make a .php or a .pphp file. After a few days i will just say to my self f*** this sh** and just stick with the .php. My coleague will just stick with .php - he values his time and to him this will be just noise that he ignores because it gives no real benifit, IDE's and editors will ajust in time and reformatting a whole project is just a waste of time. Not to mention frameworks will not follow for a long time because of the BC and big WTF factor. As I said, if that is the case, then you shouldn't be using a .phpp file. This new file type is NOT intended to replace .php, not even partially. Most of your work will likely still be done in .php scripts. This new .phpp type is for specialized instances when you know you won't be using raw HTML output. This happens a lot, but it may not happen in your application. If it doesn't, then don't worry about it. There's no WTF factor to it and there's DEFINITELY *no BC breakage, period!* If your application doesn't have a need for pure PHP code, then don't use it. I'm not sure why you think the mere existence of this file type will somehow magically break all your .php files.
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Fri, Apr 13, 2012 at 7:15 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2012-04-13, Kris Craig kris.cr...@gmail.com wrote:
On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur john.lesu...@gmail.com
wrote:
//a controller, maybe a class, maybe just a set of functions, but in a
.phpp file
function getLoginPage()
{
//set up some data
//some people like to use plain .php for templates
include 'templates/loginPage.php';
//other people like to use a View library
$view-render('loginPage.tpl');
}
In the case of using a view object, your controller can be a .phpp
file.
In the case of the include, it cannot. Now consider the case of the
implementation of the render() method:
function render($template)
{
$compiledTemplate = $this-compile($template);
include $compiledTemplate;
}
Now your render method cannot be in a .phpp file.
Again, the controller should NOT be a .phpp file. Likewise, your model
should NOT be hooking directly to the view. The controller hooks to the
model. The controller then sanitizes that and returns it to the view.
Alternatively, if you're not conforming to a pure MVC standard,
Sorry, this is where you lose me. There's no pure MVC standard,
particularly when it comes to MVC implementation on the web. There are
many, many, many interpretations of how MVC works, and some generally
accepted understanding around separation of concerns, but if you look at
the ecosystem of MVC frameworks in PHP alone, you'll see that none of
the frameworks do things the same way.
Yeah I went a bit overboard on the whole MVC purity soapbox. I do
believe that this way is the correct approach, but deriding all other
architectures as broken was a bit much.
On top of this, there's an argument that you're not addressing: most
template engines in PHP either directly consume PHP template files...
or compile templates into... PHP template files. As such, sooner or
later, you'll have a class that includes a PHP template file, and that's
where things break for me in this proposal.
They don't break because nobody in their right mind would ever try to
include a .phpp file in a framework like that. If its stack is so
entangled, the very notion of a pure PHP stack is just incompatible. So
your best bet on a framework like that would be to stick with .php.
I think the pure PHP vs embedded PHP has to be determined in a
file-by-file basis, if at all -- NOT based on whether or not a file is
consuming a file that has embedded PHP. Once you go down that rabbit
hole, as soon as you have one file with embedded PHP (and most likely,
you will), you'll have to assume the entire project is. At that point,
there's zero benefit at all to making a distinction.
I believe the exact opposite to be true. If you expect a file you're
including to output *only* pure PHP code, but then it outputs a bunch of
HTML code, it shouldn't matter whether that code came from the file itself
or an included file. The result is the same either way. If that doesn't
treat them both the same, that lack of consistency basically makes the
whole point of including a pure PHP stack useless.
Alternatively, I suppose we could create a third type; one that goes on a
per-file basis instead of per-stack. While I personally don't see any
value to this, a few of you are expressing a desire for that, so I'd be
willing to meet you halfway on this and add that to the RFC.
The proposals to use a flag with include, or to provide a separate
script() function for switching between pure PHP/embedded PHP make
sense to me. These make it easy for a framework/project to provide
autoloaders that choose the appropriate flag/function necessary to load
the class, and to select the appropriate flag/function when including
embedded artifacts. They also make auditing code easy -- you can grep
for one or the other.
The problem with that is you're basically creating two separate methods for
parsing the same file. Inherently, one of those methods will always work,
and the other method will always break. That makes no sense to me. If a
PHP script doesn't contain a ?php tag but it's all PHP code anyway, the
only keyword under your model that would ever work is script().
Conversely, if it does have a ?php tag and/or ? content, the only keyword
that would work is include()/require(). So that completely defeats the
whole purpose of having separate keywords, since by definition the
distinction is still handling at the file-level anyway. So rather than
creating meaningless keyword distinctions, differentiating the file
extension is the logical approach.
File extensions, on the other hand, are a non-starter, as is any
approach that would insist that any consumer of a script that uses
embedding be marked as embedded as well.
See above. Using separate keywords doesn't change this; it just makes it
more confusing and tedious.
RE: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On top of this, there's an argument that you're not addressing: most template engines in PHP either directly consume PHP template files... or compile templates into... PHP template files. As such, sooner or later, you'll have a class that includes a PHP template file, and that's where things break for me in this proposal. They don't break because nobody in their right mind would ever try to include a .phpp file in a framework like that. If its stack is so entangled, the very notion of a pure PHP stack is just incompatible. So your best bet on a framework like that would be to stick with .php. Um, so if you aren't using any form of template engine whatsoever, what are you proposing? You're saying we should all go back to the good ol' C days of trying to put together valid markup using string concatenation? (Or worse, manipulation of DOM classes?) No thanks. IMO this is a bit like blowing up London to stop a jaywalker. After a lot of thought I've decided that I'm strongly opposed to the nature of this proposal at a fundamental level. It isn't that I just wouldn't use it. This proposal is inherently destructive to the PHP development community. This effectively attempts to split PHP into two languages. Current PHP isn't really compatible with the proposed .phpp version of PHP, in the sense that you can't safely use both in the same code base. Unfortunately this will not be clear to anybody at first, which will lead to mass proliferation of .phpp libraries which are like poison to any unsuspecting PHP user foolish enough to try to use one. This isn't just a BC thing, it is really a permanent language fork. John Crenshaw Priacta, Inc. -- I am using the free version of SPAMfighter. We are a community of 7 million users fighting spam. SPAMfighter has removed 839 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len The Professional version does not have this message -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw johncrens...@priacta.comwrote: On top of this, there's an argument that you're not addressing: most template engines in PHP either directly consume PHP template files... or compile templates into... PHP template files. As such, sooner or later, you'll have a class that includes a PHP template file, and that's where things break for me in this proposal. They don't break because nobody in their right mind would ever try to include a .phpp file in a framework like that. If its stack is so entangled, the very notion of a pure PHP stack is just incompatible. So your best bet on a framework like that would be to stick with .php. Um, so if you aren't using any form of template engine whatsoever, what are you proposing? You're saying we should all go back to the good ol' C days of trying to put together valid markup using string concatenation? (Or worse, manipulation of DOM classes?) No thanks. IMO this is a bit like blowing up London to stop a jaywalker. That's a logical fallacy; i.e. your contention relies on the premise that, if this doesn't work with every single framework known to exist, then it doesn't work with any template engine whatsoever. That's just patently ridiculous and could not be further from the truth. After a lot of thought I've decided that I'm strongly opposed to the nature of this proposal at a fundamental level. It isn't that I just wouldn't use it. This proposal is inherently destructive to the PHP development community. This effectively attempts to split PHP into two languages. Current PHP isn't really compatible with the proposed .phpp version of PHP, in the sense that you can't safely use both in the same code base. Unfortunately this will not be clear to anybody at first, which will lead to mass proliferation of .phpp libraries which are like poison to any unsuspecting PHP user foolish enough to try to use one. This isn't just a BC thing, it is really a permanent language fork. A few points: 1. How exactly will this single-handedly destroy the PHP community? I will give you bonus points for creative hyperbole, though. 2. This does NOT split PHP into two languages. In fact, there are no changes to the language in this RFC. The only difference is a new file type that parses PHP without the need for a ?php tag and with ? raw HTML code not being permitted within that file type's stack. Again, bonus points for wild hyperbole 3. Current PHP is perfectly compatible with this, as would be many if not most implementations (some might require more work than others). And those that aren't aren't being forced to use this new file type in their projects anyway. I think what's at issue is the particular framework that *you* are accustomed to working with would not mesh well with this. But that's a very narrow subset of PHP. The language itself and probably most implementations of it would have no problem incorporating this if they chose to do so. The all or nothing mindset you're expressing is not logical. 4. For the gazillionth time, *there is no BC break in this RFC!* The language is not being redefined as you're characterizing it and .php files will continue to behave *exactly* as they do now. 5. Using cheap fear tactics like any unsuspecting PHP user foolish enough and poison only serves to cheapen this discussion and erode your own credibility. --Kris John Crenshaw Priacta, Inc. -- I am using the free version of SPAMfighter. We are a community of 7 million users fighting spam. SPAMfighter has removed 839 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len The Professional version does not have this message
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On 2012-04-13, Kris Craig kris.cr...@gmail.com wrote: --f46d04447f47ae95ec04bd949e5f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw johncrens...@priacta.com wrote: On top of this, there's an argument that you're not addressing: most template engines in PHP either directly consume PHP template files... or compile templates into... PHP template files. As such, sooner or later, you'll have a class that includes a PHP template file, and that's where things break for me in this proposal. They don't break because nobody in their right mind would ever try to include a .phpp file in a framework like that. If its stack is so entangled, the very notion of a pure PHP stack is just incompatible. So your best bet on a framework like that would be to stick with .php. Um, so if you aren't using any form of template engine whatsoever, what are you proposing? You're saying we should all go back to the good ol' C days of trying to put together valid markup using string concatenation? (Or worse, manipulation of DOM classes?) No thanks. IMO this is a bit like blowing up London to stop a jaywalker. That's a logical fallacy; i.e. your contention relies on the premise that, if this doesn't work with every single framework known to exist, then it doesn't work with any template engine whatsoever. That's just patently ridiculous and could not be further from the truth. Then point to ONE widely used, OSS templating engine or MVC framework that will be able to operate as pure PHP. (My mustache library does not count.) I'll give you time to look for one. Hint: I don't think you'll find any. Most PHP template engines compile templates to HTML with embedded PHP. This does NOT mean that including such a PHP file immediately spits out output -- on the contrary: every PHP templating engine I've seen by default will use output buffering to allow capturing the output to a variable, which you _later_ spit out. This is one reason I'm very uncertain about your assertion that including an embedded PHP file taints the class including it, as well as any up the stack. The code itself is never really operating in mixed or embed mode -- only the template file itself is. If you insist on the tainting aspect, I honestly do not see this proposal gaining ground; few if any exising frameworks or template engines will gain anything by it, much less be able to take advantage of it, and the work necessary to make it possible makes it undesirable, except as an achievement (look! I did it!). Finally, you're constantly dismissing the arguments that specifying a specific suffix is a bad idea -- but without making a reasonable argument as to why suffixes are okay. I personally write a lot of CLI scripts in PHP -- and typically do not give them extensions. Under your proposal, even those these do not operate in embed mode, because they do not have the blessed extension, they cannot omit the ?php tag. This is limiting, and goes against the idea of portability. I'm not going to go as far as John and claim it's an attack on existing users or anything -- but I will argue that you're ignoring very, very common use cases and patterns used in PHP, and over-estimating how likely people will want to use the feature as proposed knowing the limitations. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Fri, Apr 13, 2012 at 1:02 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2012-04-13, Kris Craig kris.cr...@gmail.com wrote: --f46d04447f47ae95ec04bd949e5f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw johncrens...@priacta.com wrote: On top of this, there's an argument that you're not addressing: most template engines in PHP either directly consume PHP template files... or compile templates into... PHP template files. As such, sooner or later, you'll have a class that includes a PHP template file, and that's where things break for me in this proposal. They don't break because nobody in their right mind would ever try to include a .phpp file in a framework like that. If its stack is so entangled, the very notion of a pure PHP stack is just incompatible. So your best bet on a framework like that would be to stick with .php. Um, so if you aren't using any form of template engine whatsoever, what are you proposing? You're saying we should all go back to the good ol' C days of trying to put together valid markup using string concatenation? (Or worse, manipulation of DOM classes?) No thanks. IMO this is a bit like blowing up London to stop a jaywalker. That's a logical fallacy; i.e. your contention relies on the premise that, if this doesn't work with every single framework known to exist, then it doesn't work with any template engine whatsoever. That's just patently ridiculous and could not be further from the truth. Then point to ONE widely used, OSS templating engine or MVC framework that will be able to operate as pure PHP. (My mustache library does not count.) I'll give you time to look for one. Hint: I don't think you'll find any. Why would I want to prove a point that I was never trying to make in the first place? I've never contended that there are frameworks that are 100% pure PHP code. That's not a requirement for .phpp anyway. So I'm not sure why you're introducing that idea all of a sudden. Most PHP template engines compile templates to HTML with embedded PHP. This does NOT mean that including such a PHP file immediately spits out output -- on the contrary: every PHP templating engine I've seen by default will use output buffering to allow capturing the output to a variable, which you _later_ spit out. See above. This is one reason I'm very uncertain about your assertion that including an embedded PHP file taints the class including it, as well as any up the stack. The code itself is never really operating in mixed or embed mode -- only the template file itself is. If you insist on the tainting aspect, I honestly do not see this proposal gaining ground; few if any exising frameworks or template engines will gain anything by it, much less be able to take advantage of it, and the work necessary to make it possible makes it undesirable, except as an achievement (look! I did it!). Finally, you're constantly dismissing the arguments that specifying a specific suffix is a bad idea -- but without making a reasonable argument as to why suffixes are okay. That's false. Please refer to my previous messages from today. I explained in detail why a filename extension is preferable to new keywords. Rather than forcing me to repeat myself, please read what I've already posted on the matter. I personally write a lot of CLI scripts in PHP -- and typically do not give them extensions. Under your proposal, even those these do not operate in embed mode, because they do not have the blessed extension, they cannot omit the ?php tag. This is limiting, and goes against the idea of portability. I'm not going to go as far as John and claim it's an attack on existing users or anything -- but I will argue that you're ignoring very, very common use cases and patterns used in PHP, and over-estimating how likely people will want to use the feature as proposed knowing the limitations. I think you're the one who is ignoring what's being said. I offered a compromise solution that addresses your concerns and neither of you have even acknowledged it, let alone responded to it. If you're not willing to actually read my posts and look for common ground, then there's no reason for me to say anything further. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Thu, Apr 12, 2012 at 6:35 PM, David Muir davidkm...@gmail.com wrote:
On 13/04/12 11:03, Kris Craig wrote:
On Thu, Apr 12, 2012 at 5:46 PM, David Muir davidkm...@gmail.com wrote:
On 13/04/12 10:04, Kris Craig wrote:
On Thu, Apr 12, 2012 at 4:46 PM, David Muir davidkm...@gmail.com wrote:
On 13/04/12 09:38, Yasuo Ohgaki wrote:
Hi,
2012/4/13 Kris Craig kris.cr...@gmail.com:
Per recent discussions, I have drafted an RFC for this. This proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.
https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.
CLI may use .phpp as PHP script always. (i.e. execute w/o ?php or
else)
It's like DOS, though.
How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?
A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
thrown for require; in both instances, the included file will be ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.
That's actually not true. Please refer to the diagram embedded in the
RFC.
Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included from a
regular .php file, which also would include whatever you're using for your
templates. In other words, they can interact just fine; you just can't put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad architecture.
How is this bad architecture? Every framework I've seen that has some
kind of templating layer that handles the scope and inclusion of the
template, and it happens further down the chain from the controlling code.
Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.
In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers, and some
services would have to remain as .php so that templates could be executed.
Oh, and the autoloader can't be .phpp either. But then if it's .php, then
the autoloader can't be called from .phpp files to include .php files.
Cheers,
David
It's been awhile since I've used Smarty, but unless my memory is failing
me, I'm pretty sure it's not restricted to being several points removed
upstream as you described. I'm not familiar with Zend_View or Twig so I
can't comment on those.
Thing is, there's no reason why you can't hook any framework into this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on top of
it, then use that same controller class to interface with the .phpp stack.
Problem solved. It's really not as complicated or confusing as you're
making it out to be.
--Kris
Both Smarty and Twig compile your template files down to php templates.
Zend_View, Aura.View, and Symfony's php view include php files directly
without a compilation phase.
I don't get how I would write a simple controller class layer to operate
on top of it.
Does the inclusion limitation apply to just the script in question, or the
entire call stack?
A simplified example:
index.php - FrontController.phpp - Controller.phpp - View.phpp - can't
include template.phtml
index.php - FrontController.phpp - Controller.phpp - View.php - can
include template.phtml ?
But I can't do require_once('View.php') in the controller.
If there's an autoloader involved, it would have to be set up in
index.php, and would also have to be .php so that it can include both file
types.
index.php - FrontController.phpp - Controller.phpp - Autoloader.php -
can include View.php ?
But will that work since there are .phpp files above it in the call stack?
Cheers,
David
I'm sorry, I was vague on this point in my previous response. The
controller script would be standard .php, not .phpp. And rather than a
one-dimensional linear progression, there would be parallel stacks, one
.php and the other .phpp, both coming together in the controller (which is
.php).
If I get some time this weekend I'll try to throw together a working
example.
