+1 > On Feb 5, 2015, at 5:23 PM, Adam Harvey <ahar...@php.net> wrote: > > On 6 February 2015 at 04:14, Andrea Faulds <a...@ajf.me> wrote: >> At long last, I’m going to put the RFC to a vote. It’s been long enough - I >> don’t think there needs to be, or will be, much further discussion. > > True, and I probably won't respond to any replies to this because we > don't need more noise, but I do want to explain my -1 vote. This is > long and rambling. I apologise. I've posted a formatted version of > this at https://gist.github.com/LawnGnome/354ca07f1799ff88fc35 in case > it's easier to read. > > In no particular order, my issues with this RFC: > > ## The declare switch > > Adding the cognitive overhead for each file for developers to have to > remember whether they have to cast a value before passing it to a > function or if PHP will automagically do that for them is a bad thing. > Of course, in a small, well compartmentalised file, or a single > developer code base, it wouldn't be a problem. Unfortunately, a lot of > PHP projects aren't that tidy. (Probably most of them, in fact.) > > I also disagree with the comparisons that have been drawn on Internals > between `declare(strict_types=1)`, `use strict`, and `from __future__ > import foo` statements. They're not the same thing at all: > > * `use strict` is ultimately about code quality — am I doing something dumb? > * `from __future__ import foo` is ultimately about features — yes, I > want to opt-in for the new shiny. > * `declare(strict_types=1)` isn't either of those, although it might > superficially appear so — what it's really about is "I reject your > philosophy and substitute my own" in terms of typing. > > There are structural decisions we can and should let our users make. I > believe this isn't one of them: allowing users to fundamentally change > the typing semantics of a language on a module-by-module level is, in > my opinion, insanity. Languages have to be opinionated about this sort > of issue: if they weren't, there'd only be one programming language > and it would have 800 switches to configure before you could write a > line of code. This sort of decision is the whole point of designing a > language: abdicating it by providing a switch is effectively us > shrugging and saying "sure, whatever, we don't care, so now we'll make > you care". > > ## Strong typing > > This ties into the previous point: for scalars, PHP has never been a > strongly typed language. I was once on the train of strict typing > being universally better — if you know that you always have an > integer, you never have to worry about a bad conversion, right? And, > if I was designing a language from scratch, I'd probably still feel > that way. > > That language wouldn't be PHP, though. PHP is unapologetically weakly > typed from top to bottom. Designing a feature to break that would be > bad enough. Designing a feature to optionally break that is insidious. > If you care about whether the zval IS_STRING, you can check that > today. Encouraging our users to care goes against the entire > philosophy of the language. > > To be clear: yes, we have problems in our type conversion matrix. The > fact that `"21 Jump Street" == 21` is an issue (particularly because > it's silent), and we should be talking about that. But strong typing > is not the solution. > > ## Caller versus callee > > Making the caller responsible for choosing the type behaviour is a > clever hack. (No pun intended, Facebookers.) I find the idea > intriguing from an academic perspective. Unfortunately, as with the > above point, this isn't consistent with PHP as a language that's > existed for 20 years and had type hinting in its current form for over > 10 years. If we accept this, then we only widen the gap between scalar > values and array/object ones: for one set of type declarations, the > behaviour is determined entirely by the callee, and for another, it's > determined by both the callee (via the type hint) and the caller > (whether it will be converted or not). > > ## So what do we do for 7.0? > > From where I sit, we had a good solution: it was the 0.1 version of > this RFC. It behaved like PHP should behave, respected PHP's long > standing scalar type handling and conversion rules, but most > importantly, it solved the **actual** problem scalar type hints are > supposed to solve in the simplest possible way: > > Can I guarantee that my function that expects an integer will > really get an integer? > > I don't think that adding complexity on top of that helps anyone in > the long run. Yes, we get to tick some extra boxes — "we support > strong typing", "we support weak typing", "we put the user in control" > — but at the cost of having a language that not only supports, but > advertises multiple, inconsistent behaviours, requires users to be > aware of conversion minutiae that they shouldn't have to be mindful > of, and doesn't do anything to solve the actual problem above. > > Adam > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
