Hi, > On 13 Feb 2015, at 09:37, Patrick ALLAERT <patrickalla...@php.net> wrote: > > Voted "no" because of the reasons already mentioned by a bunch of others here. > > Weak type hint as presented earlier: +1 (and very good job Andrea about > that!). > declare(strict_types=1): -1, not only about the syntax, but also about the > mixed mode it introduces. > > I'm pretty confident that this RFC will "pass" with just above 2/3 of > majority while it could reach much more. > > I am pretty sure that if this RFC doesn't include a strict type mode _the > way it is proposed_ (or even, not at all, as part of another related RFC), it > would have some "no" converted to "yes" and would have a wider adoption, > which is for sure a better option than relying on a voting mechanism which > still is a supporting tool, we're not politicians after all :)
It wouldn’t have wider adoption. Excluding a large portion of the PHP community (which favours strict types) and giving them something which doesn’t work for their use cases (weak types) is not going to win any fans. > Andi's suggestion about an E_STRICT_TYPES sounds very reasonable and much > more in line with how PHP deals with "errors”. I don’t think E_STRICT_TYPES is a good idea. Global error handlers are, well, global. They not only affect your own code, but everything within the request, including libraries you use. So you can use them (and break every library you use), or not use them (and now it’s useless). What this RFC does is let individual files choose one mode or the other. This is far better for interoperability. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
