On Sat, Feb 21, 2015 at 2:47 PM, Zeev Suraski <z...@zend.com> wrote: >> "with two potential 'camps' of developers forming up" >> >> Have you looked at the community lately? That's been happening for a >> decade. One camp likes to engineering everything out using classes and >> libraries. The other keeps using PHP procedurally and ignoring changing >> "best >> practices" (and I do mean the quotes). Does that make one better than the >> other? NO. > > I don't think these two camps map to the strict and dynamic camps, > definitely not for the userbase at large.
Actually yes, it is slightly like that. > Which means that whatever camps we have today, we'd have more - one extra > point of division. We do, while one RFC allows a smooth, BC breaks free (100% safe) migration path to 7 for existing apps or code. >> And that's PHP's strength. It gives both sides the power to keep doing >> what >> they want to be doing without having to give up or be burdened by the >> other >> side. > > I explained both in the RFC and here why I don't think providing two modes > for doing something quite similar are good. We can agree to disagree :) And I explain here many times why changing the casting rules is a bad risky idea to begin with. >> Sure, some people will do that. Just like people still use single quotes >> because >> they are faster. > > Not quite IMHO - that example actually requires some relatively advanced > knowledge. Strict, with the amount of noise that Scalar Type Hints are > bound to get (and are already getting) - is bound to have a lot more > exposure than single quotes being faster ever had. And it's therefore very > likely it'll be used by people who shouldn't really be using it. > > Let's leave the Static Analysis part aside, and agree to disagree as we > already did numerous times but failed to implement. Pure suppositions and again extrapolating from nothing. It is as always a documentation matter and as usual many users won't even know it exists and simply update PHP. It should work smoothly, without BC and that's what will happen by default if we don't change the default way to deal with casts. >> > Two more things regarding the competing RFC – it’s still alive, and >> > being promoted for PHP 7.0; And while it doesn’t create a huge BC >> > break, it allows developers to selectively create localized BC breaks, >> > on a per file basis. >> >> No, it does not. A BC break is something where existing code works, and >> you >> do nothing more than upgrade and have the new code not work anymore. >> >> With the other dual-mode RFC, if a user opts-in (enables strict mode), if >> code >> doesn't work that's not a BC break. That's a case of "you told us explicit >> you >> don't want this code to work if it's invalid, and guess what, it's >> invalid". > > That's splitting hairs IMHO. The bottom line is that many people will > undergo the same process Rasmus did as he experimented, flipping the switch > on because it's a best practice, and start having to fix their code to work. > But we can also agree on what we always agree here too :) It is not splitting hair, it is the key point of the dual mode. A given user can simply ignore the type hinting and keep using what its apps do, and it will work. He can as well focus one area, or addon to its app, to use strict mode (and will only apply to the files used by this specific addon and nowhere else!! ). With the other RFC, which changes the casting modes, I wish everyone good luck. I may be wrong, can happen ;), but we simply do not know and will not know before 7.0.0 is out. Good luck to change them again to "adapt and tweak", and good luck to the apps developers to adapt their apps with plenty of patch versions checks. This is the reason #2 why I am against your RFC, the #1 being the total lack of actual non magic casting (read: strict), optionally enabled. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
