Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88175 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 69634 invoked from network); 13 Sep 2015 13:15:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Sep 2015 13:15:03 -0000 Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.6 as permitted sender) X-PHP-List-Original-Sender: francois@php.net X-Host-Fingerprint: 212.27.42.6 smtp6-g21.free.fr Received: from [212.27.42.6] ([212.27.42.6:26659] helo=smtp6-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 47/16-06745-6D675F55 for ; Sun, 13 Sep 2015 09:15:03 -0400 Received: from [127.0.0.1] (unknown [82.232.41.54]) (Authenticated sender: flaupretre@free.fr) by smtp6-g21.free.fr (Postfix) with ESMTPSA id B0AE282243; Sun, 13 Sep 2015 15:07:24 +0200 (CEST) To: Bob Weinand Cc: Sean DuBois , PHP Internals References: <55EE1293.7020404@php.net> <55F4D03D.2050902@php.net> Message-ID: <55F576D0.6060106@php.net> Date: Sun, 13 Sep 2015 15:14:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 150912-5, 12/09/2015), Outbound message X-Antivirus-Status: Clean Subject: Re: [PHP-DEV] strict-api - Proposing a tool to check and enforce encapsulation From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=) 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