2011/5/10 Ferenc Kovacs <i...@tyrael.hu>: > > >> >> The Tainted Variable RFC - https://wiki.php.net/rfc/taint - personally >> I would prefer that feature right now over any new feature, because it >> gives the ability to check for insecure variable handling and make >> sure you don't miss something. A major security enhancement on the >> language level (how the people can and will abuse it is not the issue >> - people do SQL selects in loops - tainted variable abuse is just >> negligent compared to that one) - isn't it worth the effort to finish >> that and release? > > http://marc.info/?l=php-internals&m=129009775610865&w=2 >
Well, there is the impact, but seriously, do that many people will use it in production? I certainly will not, but on the DEV and on my local development machine it will be enabled period. >> >> The Lemon parser - https://wiki.php.net/rfc/lemon - I remember a lot >> of discussions on that and work being done and people wanting to do >> it. What happened? >> > > http://marc.info/?l=php-internals&m=128872242418092&w=2 > and as a bonus: > http://marc.info/?l=php-internals&m=128864465522116&w=2 > The thing here is that there seems to be no movement at all. As I remember, there just has to be work done to write the grammar parser in Lemon in a such way, that it is fast enough and would have range for improvements. Right now it seems that no one is even trying. >> >> Error handling RFC's - https://wiki.php.net/rfc/error-optimizations >> and https://wiki.php.net/rfc/enhanced_error_handling - it's sitting >> there for quite some time. Any thought on that? Because error handling >> improvements will benifit all PHP developers - every single PHP >> developer out there in the wild. >> > http://marc.info/?l=php-internals&m=126218949715825&w=2 > Yep, bad suggestion from my side :) >> >> PHP Native Interface - https://wiki.php.net/rfc/php_native_interface - >> sounds and looks like a good and important project. > > yeah, but AFAIK it wasn't finished, and by the comments I'm not entirely > sure that it's possible or viable at all. > http://marc.info/?l=php-internals&m=123901102014697&w=2 > It was more like an example of abandoned projects witch stay on RFC page for long time and make an impression that it will be dealt with. Just move it to "Not accepted/Abbandoned" category then. >> >> And I even will not touch the topic of type hints and return type >> hints. At least param type hinting should be dealt with and done >> something about it, because right now it's at a half-completed state - >> only arrays and objects are supported. > > that's a touchy subject. > Indeed it is. But at least the param type hinting should be finished, cause it's all ready half there. >> >> And probably the RFC wiki should be looked at and sorted out - there >> are some things implemented and rejected, witch haven't been moved to >> proper sections. >> > > +1 > >> >> Said all that - I think annotations should be dropped for 5.4 for now >> and the development and refining continued until it's properly >> scrutinized, tested and ironed out. Right now to focus on delivering >> stuff that's all ready done or near completed (performance >> improvements for example) and look at the backlog and bugs. >> > > "One of things I love most about working with Open Source Software like PHP > is the freedom. If I have an itch, I scratch it! If I want to work on new > features or document all the kinks and quirks of PHP, I can. We have the > freedom to work on exactly the things we care about and want to do." > so the problem is, that the userland is under-represented in the > development, because they usually not present on the mailing list and on > irc, where discussions and decisions happen, and they usually have different > priorities and expectations about the PHP language than the core devs. > to make things worse, they cannot write patches for the core, and the core > devs rarely work on something which they don't particularly need or like. > and I think that the only option where we can change that, is that us, the > php userland devs has to be more active on the mailing lists, irc, bug > tracking, writing RFCs etc. Yes, it is the problem. And usually the userland developer voices are just overflown by other people - core devs and people who invest in developing their own stuff. Maybe core devs could somehow highlight the things that userland developers are writing? > ps: > "Right now I think PHP has reached a milestone, where it is a need to > take a break from large feature developing" > your suggestions also contains really large features. > I would add the unicode and LFS support for that list. > they are both long requested features, and nothing really happening to solve > those. > > Tyrael That was the intent of my e-mail in the first place - to show that there is a ton of stuff that is in questionable state, half done or most of the problems solved and it just needs some love to become production ready. There has to be a re-focus for some time. PHP 5.2-5.3 where a good example of cleaning up, speeding up and very good feature development - anonymous functions for example are just freaking awesome stuff. It is a good idea to look at all the big stuff that is just begging to be fixed/added/done - Unicode is really the pain in the ass (especially for me, because I have to work with multi-language websites and systems - Russian, Latvian, English, Arabic and other). There just has to be some sort of core developer decision to stop actively developing new features and just clean up the backlog. Community probably will follow with that too. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
