And actually, I would plea for a moment of sanity right now. As far as i'm concerned - the RM for the 7.0 had to step in a long time ago and said "guys, I do not accept any typehint proposals into the 7.0 release, work it out and come back for 7.1". Because if this would be a commercial development before a release - feature would be scrapped and re-sheduled for later release. Why? Because the clusterf**k happened at RFC level already, the development itself is going to be haisty considering the timeline and definetly being bombarded by the protesters, countless critisism and so on. It is going to affect the projects. And that is a bad thing. Look past the damn typehint RFC's and just try to asses the big picture. Right now it's a tunnel vision for many on the list.
сб, 14 Мар 2015, 1:29, Arvids Godjuks <arvids.godj...@gmail.com>: > Opcode caches just cache the compiled code - you still need to load the > code into the engine, do checks for file modifications and other stuff. > > Yes, if you are a badass and have full controll, all that can be solved. > Reality, however, is one big f***up. I had to fix a lot of weird stuff, > including the cases where there was some kind of opcode cache and it still > was horrible. Or shared enviroment. Or just bad code. You havent seen > FTP/SFTP project deployment in last few years? I envy you. You work for > godly clients. Or it's just that you are a rockstar in a rockstar friendly > company with resources and will to do things right. But most of us a far > lower in the food chain. We have to deal with things that would give you > nightmares. > > Or take most of Open Source PHP code - besides a few high quality projects > like Symfony and the bunch, it's bad. And I know one instanse of an Open > Source project with PHP part that will go full retard mode with strict > typehints no matter the cost or consiquences. Probably will end up killing > the company behind it in the long run. > > There is one thing that you learn when you actually go beyound the coding: > never ever give user a choise - he doesn't know what he wants anyway. He > thinks he needs one thing, in reality tests show absolutelly different > stuff. You need to make a decision select a way you wana do it. It newer > works out with choises - people always make a mess. > > сб, 14 Мар 2015, 1:11, Benjamin Eberlei <kont...@beberlei.de>: > > On Sat, Mar 14, 2015 at 12:02 AM, Arvids Godjuks <arvids.godj...@gmail.com >> > wrote: >> >>> пт, 13 Мар 2015, 23:01, Philip Sturgeon <pjsturg...@gmail.com>: >>> >>> > Pavel, >>> > >>> > On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil <pajou...@gmail.com> >>> wrote: >>> > > On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara < >>> ircmax...@gmail.com> >>> > wrote: >>> > >> >>> > >> But for today, I firmly believe that the Dual-Mode proposal is the >>> > >> only one that stands a chance of passing. I think it's the best >>> chance >>> > >> for the language, and it's the only one that tries to unite the >>> > >> different usages of PHP into a single group, rather than alienating >>> > >> users. >>> > >> >>> > > >>> > > Hello, >>> > > >>> > > I see (as a userland developer) these problems with dual mode: >>> > > - It is a "setting" that changes the language's behavior; I don't >>> > > think that it matters whether or not it would be an INI setting or >>> the >>> > > declare() one, because both of them are bad. >>> > > - It does not "unite different usages of PHP into a single group"; it >>> > > does exactly the opposite, splitting PHP usage into TWO groups. >>> > > - Once this dual mode would be introduced to PHP, there would >>> probably >>> > > be no way of removing it later without massive BC break, once most >>> > > people would realize that it is really awful to have it in the >>> > > language. >>> > > >>> > > (There's probably more of them, but these are the biggest issues I >>> > > currently have.) >>> > > >>> > > Regards >>> > > Pavel Kouril >>> > > >>> > > -- >>> > > PHP Internals - PHP Runtime Development Mailing List >>> > > To unsubscribe, visit: http://www.php.net/unsub.php >>> > > >>> > >>> > Hang on. This is not the time to nitpick things in various RFCs that >>> > have already been answered time and time again. >>> > >>> > An ini setting would be insane because taking an app that works on one >>> > machine and putting it on another would completely break the app. >>> > Hello anything using Composer, hello any CMS, hello any system moving >>> > to a new host that doesn't let you change ini settings, or you dont >>> > know how. >>> > >>> > A declare statement in the top of the file changing how that file >>> > handles things is hardly a problem, and is exactly how a lot of other >>> > languages do things. Hello JavaScript. >>> > >>> > It seems like you didn't read anything now you're just saying "it's >>> > bad" a lot. Please don't do that. >>> > >>> > -- >>> > PHP Internals - PHP Runtime Development Mailing List >>> > To unsubscribe, visit: http://www.php.net/unsub.php >>> > >>> > That declare thing with the removal of block-aware declare(){} kills >>> one >>> of the fundamental optimizations you can do for large PHP projects - >>> compacting most used files into one single big file and caching it. And >>> you >>> never had to care what the files are - just splice it all together and >>> let >>> autoload handle the rare cases. With single declare statement I >>> effectivly >>> have to scan all the code, remove declare statements and choose a mode >>> globally. Well, it might work for a small project, but in a big project >>> with multiple teams or even multiple vendors doing different parts.... >>> >> >> The same is true for namespaces, but Symfony for example works around it >> by introducing block syntax. >> You can just remove the declares, during concatenation, or move a single >> strict to the top. >> >> Also this is not a fundamental optimization (I'd argue never has been) >> anymore since opcache is in core of PHP since 5.5 >> >>> >>> At this point I have only swearing words for the proposing persons and >>> supporters. >>> It's magic_quotes and register_globals all over again, but this time you >>> can't fix it with some PHP code. >>> >>> You really had to fuck it all up for us, the userland developers, didn't >>> you? >>> >>> Sorry, but I now question the wisdom and sanity of most new PHP folks. >>> Because the old once see the danger and vote "no". And everyone just >>> thinks >>> they act up. Well, you wrong. I will nit be surprised if they just leave >>> the project for good after this. >> >> >> This list gets pretty intense, but this kind of swearing and attack on >> persons is certainly not acceptable in my book. >> >> Like every feature, this is optional. >> >> >>
