> > > 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 template engines have to do ob magic already to be able to return the template output instead of outputting it.) ps: sorry for the wallpost, and being a little bit disorganised. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
