Hi, > De : Joe Watkins [mailto:pthre...@pthreads.org] > > > If you can infer the type with confidence, you can do away with coercion > code altogether. > > Maybe I'm ignorant of something, but isn't the only way you can begin to > infer the type with real confidence is by having strict typed parameters ? > > This sounds like the kind of strict mode we're talking about, where no > coercion is necessary because inference is so reliable given a good > starting place (function entry with strictly typed parameters).
'Weak' mode also provides full confidence on parameter zval type at function entry as they-re systematically converted. If you statically analyze PHP code starting from this point, there's no difference. The only difference is when you build the reverse tree of possible zval types in the calling environment. But, in this case, strict types just allow to restrict possible types as, in many cases, you cannot have one-to-one matching. I hope we all agree now that, in most cases, compilers (at least static ones) and code analyzers can provide smaller code and detect more potential issues in so-called strict-typing mode. What we don't agree is the downside of the architecture needed to allow this. Making a personal decision is just putting the relative perception of both aspects in balance. Let me be clear : if I didn't consider downsides more important than benefits, I would be all for enabling future compilers and static analyzers to be more performant. Anthony is an expert, the tools he wants to build are potentially interesting for the whole community, he knows his own needs better than anyone else. So, if I think this can be satisfied without making it worse for the rest of the world, why would I refuse, sadism ? Unfortunately, I think we have, at least, two major downsides here ; 1. the need for dual-mode. Actually, if we absolutely had to authorize strict types, I would still prefer it being the only available mode. Some will claim it's FUD but others will agree that no syntax or mechanism to switch modes proposed so far was really satisfying. All were more or less unintuitive and confusing, let alone the proposal to shoehorn the concept by hacking the PHP syntax or possible ambiguities against the E_STRICT concept. Even per-file activation may seem attractive on a small codebase but would probably quickly become a nightmare on a large one. I even know people currently writing composer plugins to turn it on and off on a project basis, modifying every PHP source files to add/remove the declare directive, which proves total misunderstanding of the concept, but also that proposed mechanisms don't fit so well with user needs. I wish good luck to the fooled users who will naively use such massive editing tools to improve the quality of their software... I have tried to explain from the beginning that, in most cases, especially in software architecture, 1 + 1 is not 2, and concatenating incompatible needs in an hybrid solution is not the same as merging them in a 'compromise' unified one. I read that the dual-mode RFC unifies people's needs. No, that's exactly the opposite. 2. the risk of seeing people massively consider strict mode as a way to improve their code quality without understanding the implications, potentially leading to a disaster. As I already wrote, debugging is too often assimilated with a phase to suppress error messages, trusting the compiler/interpreter, and considering that each error message implies an underlying bug : "Look, the new PHP 7 strict mode is really fantastic. I ran it on my legacy software and it detected 50 new bugs. PHP 5 was really bad, to leave so many undetected !". Then, this would automatically lead to massive explicit casting, as it is also natural to think that constraining values enhances code quality, especially if it is confirmed by the suppression of an error. The point is : we must *never*, in any case, whatever the documentation we write to explain this, allow the possibility of false errors. Don't get me wrong, people are not more dumber and more incompetent than I am. We would be fully responsible for giving them a trap, perfectly suited to fool them. In my opinion, introducing such a false feeling of quality and security is a terrible mistake. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
