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 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 > @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. But just from my initial skim, you're right that the RFC needs to be updated for clarity. I'm hoping to squeeze a little bit more out of the Internals discussion before I do so I can get some questions answered in the process. Basically, these are my outstanding questions that I'd like to see some more discussion about: 1. Should we go with a new keyword or tag? (I keep bouncing back and forth on this one) 2. Would creating a third type with looser standards (i.e. allowing regular .php to be mixed in with the stack) help alleviate the concerns that have been expressed about usability with certain frameworks? 3. If we go with the keyword approach, should we create two new keywords for each type (ugh!) or add a flag constant (bitwise?) to include and require? Sorry if your post already touched on any of this. My brain is really fuzzy at the moment lol. If we can get some good discussion and clarity on the 3 questions above, I'd feel much more confident about updating the RFC. --Kris
