Hi, Le 13/09/2015 10:41, Bob Weinand a écrit :
Well, that either just makes workflow unnecessarily complex or many devs just won't care too much about it… and these who do may be annoyed to fix others code before it's useful for themselves... (Also, I don't think like some devs will be particularly eager to recompile before each push … it doesn't take just one minute on every machine)
I'm not sure I understand what you mean. I agree that running travis checks in zstrict mode introduces additional constraints for core developers. But, I would say that's the price to pay to maintain some level of isolation/encapsulation. I know we don't always agree on the importance of encapsulation but zstrict is all about it.
The decision we need to make is whether core devs are ready to accept these constraints to maintain some level of isolation in the code. As I already said, zend_string is not the target. The real target is to eliminate tight coupling on zend_hash and other complex APIs.
Additionally, extension devs… They'd have to switch target php install while coding, just to check against zstrict install and no zstrict. Well… that just begins to become insane.
Extension devs won't have to switch between zstrict and non-zstrict PHP installs. If you look at the code, you will see that there are two configure flags, one for the core, one for extensions. Extensions will always be configured and compiled against a non-zstrict compiled core, and zstrict mode will be set in the extension configure command. It is different from other configure flags inherited from the core. So, once again, you will never keep nor use a zstrict-compiled install tree (which would be insane, I agree).
Sorry, but making zstrict optional is just plain annoying of developers...
?? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
