Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83450
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbJpd9QwhvY+an9VjsGprppRXWX0++C1w5Ogc67-7mXnw@mail.gmail.com>
References: <CAL=_i_mdb1GvYFZr1ZEqvCgZ3+um-ZYuz5xAFZuwjwBcXsEk3Q@mail.gmail.com>
	<54E5F77D.9090406@fischer.name>
	<CA+9eiLurXVtk0eKAuKF8uUb=6SVqZtatXSvZ9bnvW1gnb0hz4A@mail.gmail.com>
	<54E6F48A.9040906@fischer.name>
	<CAPwsocEiTSOM0EtFR52KNFCZNYG4dDguuyvNpk5kMKaRDwOZCA@mail.gmail.com>
	<CAL=_i_m4gUy081cMM4Aw5St4OYxVfAXK0hDZ_fSR-ChZc_UUow@mail.gmail.com>
	<54E72FE7.9030803@googlemail.com>
	<54E7312D.9090404@googlemail.com>
	<CAL=_i_m44Nbabgx56p_Lo9w5hCW-=MW3rvyh_2-B-bV7e3NkBQ@mail.gmail.com>
	<54E73E70.5020403@googlemail.com>
	<CAGa2bXZYipV0u2yOireZyrqoZY_z57cPtX_t-F6vaD3--e5U2Q@mail.gmail.com>
	<CAEZPtU7sJcfYGmZFwAO7tS+RbJafESRwU-jTPEV4_H_c8t39CA@mail.gmail.com>
	<CAGa2bXbJpd9QwhvY+an9VjsGprppRXWX0++C1w5Ogc67-7mXnw@mail.gmail.com>
Date: Sat, 21 Feb 2015 15:40:58 -0800
Message-ID: <CAEZPtU532hOi+AMwVf3-do5k8N9UdYJpfz2bzb=W+wiyV3-H1w@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Crypto Compress <cryptocompress@googlemail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0122eb9c7092ce050fa1b33b
Subject: Re: [PHP-DEV] [VOTE] Expectations
From: pierre.php@gmail.com (Pierre Joye)

--089e0122eb9c7092ce050fa1b33b
Content-Type: text/plain; charset=UTF-8

On Feb 21, 2015 1:54 PM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:
>
> Hi Pierre,
>
> On Sun, Feb 22, 2015 at 2:53 AM, Pierre Joye <pierre.php@gmail.com> wrote:
>>
>> > Assertion is only for development and testing.
>> > We need errors or exceptions during development and testing, but
>> > not in production. Therefore, errors/exception should not be catched
>> > by code in general. Isn't assertion nature?
>> >
>> > I don't insist not to enable assertion in production environment.
>> > There might be software that needs extreme reliability and stability.
>> > For these softwares, it makes sense to enable assertions and catch
>> > errors/exceptions to do some cleanups.
>>
>> This last paragraph makes me wonder why in the world assert in PHP is
>> still anything valid. If anything it should be removed, to be honest.
>>
>> Which softwares do not require to be reliable and stable? Most if not
>> all PHP written software interact with external inputs, be from APIs
>> point of view or from actual users. Per se, they have to be validated
>> and errors handling is part of this validation.
>>
>> I do see some values for asserts in unit tests, but that's pretty much
>> all I can think about it.
>>
>> All in all, I stay with my initial comment, this RFC needs more
>> discussion and some other critical questions must be answered before
>> this RFC.
>
>
> We don't put test code checks in production code, do we?
> Testing and assertion is to prevent simple bugs, to help finding bugs.
> Once development/testing is done, these code will not be needed.
>
> You may think assertion as contracts of code. Once developers ensured
> all contracts were kept, contract validations are not needed anymore.
> By this proposal, developers can check contracts anywhere in code,
> any number of times during development without sacrificing production
> code efficiency. This helps to write solid code. Assertion would be
> great tool for library/framework developers to prevent users to
abuse/misuse
> it also.
>
> Even if we test software with comprehensive manner, software has bugs.
> Assertion may help to detected/prevent "unexpected" software behavior.
> It's users choice if they enable assertions. Assertions are supposed _not_
> to do any useful checks in production, but it may help.
>
> I agree that users may abuse/misuse assertion, but most tools can be
> abused/misused like require()/include(). I agree that users _must_
> validate all input/output (and PHP should help it). These validations
must
> be done as usual code, not assertion.
>
> I hope I could explain well enough.

I pretty well know what assertions are. Thanks for the refreshing
explanation anyway :)

I do not see much gain today to "improve" them while I do not see why we
should not. It does not hurt.

My issue is more on the exception part of it and the relative unreadiness
of this rfc as well as the prerequisites, see what I wrote in my past
replies.

> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net

--089e0122eb9c7092ce050fa1b33b--