Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83319
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.192.181 cause and error)
MIME-Version: 1.0
In-Reply-To: <54E7575A.5010800@googlemail.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>
	<CAF+90c9gB67JfYG1M42YWSRLgENx3ixfghztJBN4okBRvyTCWQ@mail.gmail.com>
	<54E74ADF.9040608@googlemail.com>
	<CAL=_i_nEpEhuahRcekoH=dBm9BQd2HTFGfqPjduNzGa+wpTuoA@mail.gmail.com>
	<54E7575A.5010800@googlemail.com>
Date: Fri, 20 Feb 2015 16:24:39 +0000
Message-ID: <CAL=_i_nt8B+VO3zpu2NMDdUyYFwVuGXA0Owos8fNgcHiH2sHpg@mail.gmail.com>
To: Crypto Compress <cryptocompress@googlemail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b86f3563c7210050f877dbd
Subject: Re: [PHP-DEV] [VOTE] Expectations
From: pthreads@pthreads.org (Joe Watkins)

--047d7b86f3563c7210050f877dbd
Content-Type: text/plain; charset=UTF-8

> So it is fine to have one setting doing the exact same thing? Sorry, I
> disagree. We know we need that in other areas. Like other recent RFCs,
> we have solved them bottom-up. This one is no different.

It's fine for an RFC to be focused on one thing. This is another subject.

> So basically what you say is that this RFC, relying on things we
> should clarify and define clearly so it will be consistent across the
> engine and language, are not relevant to this RFC? I totally disagree
> and hence my point that this RFC needs more (public) discussions and
> things that are prerequisites for this RFC should be designed,
> discussed and implemented before this RFC.

I'm saying that this isn't a subject for this RFC, deciding if we're going
to have multiple exception trees is simply not in scope.

> I will certainly be the only one voting no at this stage, or maybe not
> even voting because I simply feel like you discussed that already no
> matter where and came to this RFC and say take it or leave it. I am
> not a fan of this approach or we can rename "Request For Comments" to
> "Request to Accept" as any kind of comments or feedback is simply not
> taken into accounts.

I'm sorry that you don't remember the discussion, but it did happen, the
RFC has been in (more or less) it's current form for more than a year.

The current form *is the result of discussion*.

Please stop saying it hasn't been discussed, it has, a lot.

Cheers
Joe

On Fri, Feb 20, 2015 at 3:48 PM, Crypto Compress <
cryptocompress@googlemail.com> wrote:

> To be harsh: All comments in favour of throwing exceptions here,
> substantiate theirs needs with dead, never reached and potentially buggy
> code.
> The *changed code flow in production* is the big pitfall of this RFC and
> an absolute no-go. I like zero-cost assertions but throwing exceptions is
> wrong.
>
> my 2 cents
>
>
>  ...exceptions are not used by default...
>>
>
> Can't find this point in RFC.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--047d7b86f3563c7210050f877dbd--