Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83302
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU6b4Uvmc9XyCNRaQh1Va4N=-TQRC-YZUTv1cUNPyu+Lnw@mail.gmail.com>
References: <CAL=_i_mdb1GvYFZr1ZEqvCgZ3+um-ZYuz5xAFZuwjwBcXsEk3Q@mail.gmail.com>
	<CAEZPtU6b4Uvmc9XyCNRaQh1Va4N=-TQRC-YZUTv1cUNPyu+Lnw@mail.gmail.com>
Date: Fri, 20 Feb 2015 06:22:02 -0800
Message-ID: <CAEZPtU5Lj=1_Q+8b7XYC77pOPys7h=D77sbwFnPTKCNnZrVQjQ@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] Expectations
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Feb 19, 2015 at 7:00 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins <pthreads@pthreads.org> wrote:
>> Morning internals,
>>
>>     The expectations RFC is now in voting phase:
>> https://wiki.php.net/rfc/expectations#vote
>
> I totally miss the Expectation RFC announcement. Where the RFC was
> actually proposed for discussions.
>
> I have been following up the DbC thread, seeing some mentions but
> that's it. The RFC itself popped up 3 days ago.
>
> Also the RFC itself only point to various discussions, there is no
> summary, details, docs, examples, etc in the RFC.
>
> I am sorry but as much I like (for what I think it does) as I like the
> concept, this RFC does not have, by far, the quality I would expect
> for a RFC being voted on.


Coming back to this point.

I very much like what is presented here. However I think it is pre
mature to vote on as there was (sorry) not explicit discussions about
it.

A couple of things are unclear. See the numerous questions in this thread.

I also do not like other things.

zend.assertions:

I understand we need to be able to disable them. Is production vs
development/debug mode specific to assertion? I do not think so, we
should have a more general setting for that so other areas can be used
for it.
INI_SYSTEM may also reduce the usage of this feature to local
development or dedicated hosts. Any shared hoster (those not allowing
to change php.ini) won't be able to test in similar tests environment.
It is not critical but it is something you may reconsider.

assert.exceptions:

Let solve the exception usages in the engine first and see how to deal
with them more globally, including naming, NS or where and how they
can be used. This is in my eyes a pre requise to this RFC.
INI_ALL is used here. That means that just like error_reporting (which
is actually very painful), calling some random codes may makes my code
(caller) raised exceptions when I do not want to, or the other way
round? I am not too keen on that idea.


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org