Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88176
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55F5700C.1030204@php.net>
References: <55EE1293.7020404@php.net>
	<BLU436-SMTP2006B293CD9B4C9979A627BE25F0@phx.gbl>
	<55F4D03D.2050902@php.net>
	<20150913021414.GA80662@3006.local>
	<55F5700C.1030204@php.net>
Date: Mon, 14 Sep 2015 12:00:13 +0700
Message-ID: <CAEZPtU5mQBfg5QXUQtcmgS08g4XrAd+L7n=MSZ=Kvk8mA5Qyzg@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@php.net>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP internals <internals@lists.php.net>, 
	Sean DuBois <sean@siobud.com>
Content-Type: multipart/alternative; boundary=089e011843e8d868c3051fadf09b
Subject: Re: [PHP-DEV] strict-api - Proposing a tool to check and enforce encapsulation
From: pierre.php@gmail.com (Pierre Joye)

--089e011843e8d868c3051fadf09b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sep 13, 2015 7:46 PM, "Fran=C3=A7ois Laupretre" <francois@php.net> wrote=
:
>
> Le 13/09/2015 04:14, Sean DuBois a =C3=A9crit :
>>
>> That sounds good to me!
>>
>> That would double build times though, is that going to be a concern?
>> This won't hurt development time though, since you would dev in zstrict,
>> and then switch to non-zstrict when running/testing?
>
>
> Why would it double build times ? This is an optional tool, developers
will run a zstrict build when they want to check their code against API
'best practices'. Some will do it more often than others, but that's their
choice. Some ext devs will probably never use it, that's their decision.

> The only constraint will be for core developers. If travis runs in
zstrict mode, every non-zstrict code will cause it to fail. So, core
changes will need to be 'strict'. That's why this decision needs a vote.

The more I think about it the more I think it should be part of the code
quality analysis process, like static analyzers and the likes.

Maybe a llvm plug-in or we'll configured options for existing analyzers
(like with VC)

Optional build options may not achieve what this proposal does. Except if
we enforce it.

--089e011843e8d868c3051fadf09b--