Hi! >> I look at the success of how strict types was brought in, in a way
> It was a classic compromise that neither side of the debate hated, > but neither really loved either, and the subtleties of how each mode > works are likely to be sources of confusion for years to come. I am > far from convinced that it is a model we should enthusiastically seek > to repeat. It was OK as one local compromise, but I don't think it's OK as door opening to create unlimited number of options that modify any language behavior in any file and fragment the language. One switch is two options, not ideal but manageable. 10 switches is 1024 options. Not nearly manageable. I am not sure what "success" is there - is there any evidence of strict mode being widely embraced by companies with large legacy code base? By large frameworks used by thousands or millions, and successfully deployed and maintained in mixed settings environments? I think I agree - it's a bit early to proclaim "success". There's no visible disaster (that I think would result from pushing through all-strict mode without BC provisions) but I am not sure what base for proclaiming triumph there is. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
