Larry, > Assume for a moment that: > > - we tighten up the default passing rules, such that "32" passed to an int > works but "32 footsteps" errors (which I thing most are on board with doing) > - we include a strict types mode as proposed, including the logical type > widening cases > - Zend Engine gets whatever static analysis tools you feel are appropriate. > > In what circumstances would I as a Drupal core developer (a few hundred > thousand lines of code, need high degree of correctness, 2500 developers), > contrib developer (a few thousand lines of code, medium correctness > guarantee, 3 developers), or a client consultant (a few hundred lines of > custom one-off code, 1 developer) want to enable strict mode?
So, in what circumstances? Well, I think there are a few cases we need to talk about: In legacy systems (Wordpress, existing versions, etc): In these cases, strict mode would likely go in only extremely sensitive corners. So areas dealing with cryptography, random number generation, session security, etc. And it would go in slowly, as someone revamps it. Not all at once. Just like unit testing, scalar types would be refactored in very slowly, in the critical corners of legacy systems. It's unlikely that more than 1-2% of the entire system would ever become typed. In non-legacy systems it will likely come down to developer experience coupled with benefits of the tooling to the problem. A few hundred LOC script would likely never enable strict mode, and would be just fine because of it (you can mentally keep a few hundred LOC in your head at one time). The larger the project, the more the contributors, the more the benefits to using strict mode. That's not to say that large projects would immediately go full strict. It's just pointing out that the tradeoffs would need to be weighed by the authors. The proposals that Andrea and now I have put forward give the choice to the authors, and give the power to them. If they are not convinced to go strict, then they won't. And there's nothing wrong with that. But those who do want to go strict can. The real key that you should be thinking about is when errors are detected. The stricter the type system, the earlier the errors can be detected. In a lot of cases, a strict-mode type system can detect the vast majority (if not all) of type-related errors at compile time. That's a big benefit for large projects with many moving parts. > Using strict typing would out more work on me. How much varies with the part > of the application. (Closer to IO, more work.) Having it in the language > means I will run into it sometime, even if not in code I originate. If > potential performance is not a factor, then what is my carrot? What day to > day benefit would I get from doing so other than pedantry?[1] "You can infer > things" doesn't make it clear what the day to day impact is for me. Concrete > examples, please. It's more work on you when you write a single line of code. It's less work when you're making a single line change in a 1-million-loc app. It's less work because the type system can verify that the change won't cause type errors when running (where even unit tests won't give you the same level of confidence). Beyond that, I'd highly recommend reading this article: http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-before-debating-type-systems > If it would only matter to the Facebook's of the world, well, they've got > HACK already. How would this practically help Drupal, Symfony, Zend > Framework, OwnCloud, Doctrine, phpMyAdmin, etc? Hack hasn't been out to the public for that long of a time, yet look at the buzz it's generating. Look at the frameworks that are popping up with it. Look at the libraries. I think if anything, the appearance of Hack (and its adoption) show that people want static typing, at least to some level... Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
