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.
