Hi Anthony and Zeev, On Sat, Mar 14, 2015 at 12:45 AM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> There's something that I think needs to be said about the now 3 scalar > type proposals. Please bear with me, there's a lot to say here. I'll > try to keep it as brief as I can. > > I've been working off-and-on on scalar types for over 3 years. I've > officially proposed 3 proposals and have discussed and played with > many more versions. After I left, Andrea mentioned to me that she > wanted to pick one up. So I helped her. I worked with her for months > on what was ultimately withdrawn > (https://wiki.php.net/rfc/scalar_type_hinting_with_cast). At that > point I resigned to the fact that it wasn't possible to do scalar > types in PHP. > > Andrea proved me wrong. When she came up with the dual-mode RFC in > 0.3, it was the first proposal that either of us worked on that even > had a shot of passing. She put it up to vote slightly prematurely, but > the votes were pretty clear that it was basically what people wanted, > but with a few minor "issues". When she abandoned it, I picked it up. > Partly because I wanted to see it pass (I think it's the right > proposal), but partly because I didn't want to see her efforts go in > vain by people who didn't even understand the why. > > So let me explain what I learned through that experience. Why I chose > to pick the dual mode RFC back up. Why I predicted the coercive mode > RFC would do so badly. And why I currently predict the basic scalar > type RFC, if voted on, would fail as well. > > It comes down to what people want. It became quite clear early on, > that no matter what rule set you choose, there is a non-trivial amount > of people who want something else. This is life. > > However, in this case, there are basically 3 camps: > > 1) Those that want purely weak types (what we have with ZPP now). > 2) Those that want stronger weak types (similar to what the coercive > mode proposal does, but slightly stricter) > 3) Those that want strict types. > > Each of these three camps has a non-trivial amount of members (at > least 20-30%). Personal interactions that I've had suggest to me that > the largest camp is for strong types, but even if it wasn't, it's > still not trivial. > > So what does that mean? Well, it means that no single mode proposal > can pass. Because any single mode proposal is 100% guaranteed to > alienate the needs/wants of at least 1, but more likely 2 of those > groups. > > The current dual mode proposal is the only one that I've seen that > doesn't alienate groups. It gives the purely weak camp what they want > (and by default too). It gives the strict type camp what they want. > And it lets the stronger-weak-types group choose between the two as > they want/need. Is it a perfect proposal? No. But it works for > everyone, rather than against them. > > Zeev mentioned on twitter yesterday that he wants to "at least try and > understand why people are voting no for it and turn it around" with > respect to his coercive proposal. Despite the fact that many people > have said in threads why they voted against it, let me say it again > here, really simply. There are two fundamental reasons people are > voting against it: 1) Backwards Compatibility and 2) It alienates the > needs of a portion of voters. And there's a deeper problem. In trying > to "clean up" the conversions, it partially makes it stricter than > some want (the purely weak group) and doesn't go far enough for those > that want stronger weak types. So it sits as a worst-of-all-worlds. > > Bob's pure-weak proposal (which is basically 1/2 of the dual mode RFC) > seems like a great compromise. It's simple, easy to use, easy to > understand, and can be part of a stepping stone to future modes (a > strict mode can always be added later). > > But that ignores that it doesn't give 2/3 of the people what they > want/need. It ignores that it actually makes it *less* likely for > those 2/3 to get what they want/need. Without the support of 2 of the > groups, it's unlikely that anything will ever pass. And a future RFC > to introduce a strict mode (after we have a weak mode) would be > unlikely to pass since it serves no benefit to the weak group. > > So what effectively would happen is you'd get at least 1 of the groups > (the strict group) to vote against it. And you'd get at least a few > from the stronger-weak types group to vote against it. Meaning that it > would be hard to get it passed. > > Scalar types are a **hard** problem. Not technically, but politically, > because so many people use PHP in different ways. And everyone thinks > their way is "the one true way". The dual-mode proposal is the only > one on the table that currently addresses the different needs of > different people. > > Does that mean that a single-mode compromise is impossible? I wouldn't > use the word impossible, but I certainly would use improbable. We've > been talking about this for **years**. The chances are quite high that > if a good compromise existed, it would have been found. Instead, every > "compromise" that we've seen simply throws away the needs of an entire > group. > > Should we clean up ZPP's parsing rules? Absolutely. "100 apples" > should definitely become an error. But the way to do that is not as a > last-minute change to the language rules. The way we should do that is > with MASSIVE testing to ensure that the breaks are well controlled and > warranted. This is not something that should be done in the 2 days > prior to freeze, but should be planned an executed in a really clear > timeline. Perhaps that's a good goal for 7.1 or 8.0. > > 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. > > I respectfully ask Zeev to retract his current proposal as it's > currently failing with 68% of voters voting against it (currently > 16:34). Without extending the timeline for 7, there's very little > chance of it passing. So rather than dragging out the entire process > needlessly for 2 more weeks, can we just finally be done with it? > We had long discussions for 2 RFC's pros and cons. I'm sorry that I could not keep up the discussion. This may be proposed already. The root cause of why PHP should have stricter type/conversion check, is users do have "wrong conversions". (I'm aware of other good reasons but almost all of them are to have "correct code") Anthony's proposal workarounds BC issue by having 2 modes (weak/strict) by allowing "wrong conversions" in weak mode. Zeev's proposal let users to have time for adopting new behavior and coerce to fix wrong conversions. However, "wrong conversion is wrong" by definition. "Wrong" cannot be corrected unless code is fixed. Thus, users should fix them anyway. Since both are trying to introduce strict typing to PHP for the sake of code correctness, why don't we agree to have correct type conversion by default? We care for BC. Therefore, why don't we introduce change that can spot where/what are wrong in users code at first, then change error type in PHP8? BC is not bad things to have always, but BC can do good. e.g. Enforce users to correct "wrong conversion". In other words, enforce users to have "correct codes". Current Zeev's proposal may not give users enough time to adopt. If we enforce "correct conversions" in PHP8, it would be long enough for adoption period. Since both of your objective is to have "correct conversions", let's have "correct conversions" only, let's forget about weak type hints. Weak type hint does allow "wrong conversions" and we are better to avoid it. IMHO. I think mix of your proposals would do the best. 1. Introduce E_DEPRECATED error for wrong conversions in PHP7 2. Change the E_DEPRECATED error to E_WARNING in PHP8 3. Have very strict type check that only checks zval data type. Perhaps PHP8. Regards, P.S. Simple cast can create other type of bugs as I illustrated in other thread unless we have casts that warn dangerous. Strict type check would be good low level libraries, but it will hide problems in many average users' codes by errorless casts. -- Yasuo Ohgaki yohg...@ohgaki.net
