Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82805
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.54 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAL=_i_=cYXf=yjy7y6pytg7M=pe5z8dKpriqJiG2mC_XiMXYXw@mail.gmail.com>
References: <CAL=_i_=cYXf=yjy7y6pytg7M=pe5z8dKpriqJiG2mC_XiMXYXw@mail.gmail.com>
Date: Mon, 16 Feb 2015 11:13:46 +0100
Message-ID: <CAEPJdumZvm0epREnAqEBmyj2mON3=R2=gWQ8BderFtr63g+E0g@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bd6adce7c7101050f31d703
Subject: Re: [PHP-DEV] RFC: Expectations
From: kontakt@beberlei.de (Benjamin Eberlei)

--047d7bd6adce7c7101050f31d703
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 16, 2015 at 10:37 AM, Joe Watkins <pthreads@pthreads.org> wrote:

> Morning internals,
>
>     I've had mostly negative feedback on the design-by-contract idea, maybe
> it's a step too far.
>
>     The expectations RFC in its current form proposes that we introduce
> zero-cost assertions, which are compatible with the current assertion API.
>
>     Since this has been in discussion for quite some time, Dmitry and I
> propose that the patch is rewritten for PHP7 and we get to voting as
> quickly as we are able.
>
>     Please review the RFC, and provide feedback, if there are no strong
> objections we will go ahead with a vote when the patch is ready, in the
> coming days.
>

Could you improve the PHP.INI section and explain in detail what the two
new settings do? i think its somewhere implicitly described in the RFC but
there is never an explicit description. This section should probably be it.

If this ini setting affects opcode generation, have you thought about
invalidation when changing the setting?

Do I understand correctly that this is a rebuilt of the already existing
assert() functionality? What about the old behavior? You mention its
compatible, but assert() api had a switch to decide over Exceptions vs
warnings vs quietly skip.

i think the RFC should focus more on this being an improvement of assert.
It sounds like a completly new feature.

For example:

1. you are changing assert to be an opcode instead of a normal function
2. adding the new Exception mode and that it formalizes what you could do
before by using the callback mode:

assert_options(ASSERT_CALLBACK, function () { throw new
AssertionException(); });

Otherwise i am +1 on this. It fixes some annoying features of the assertion
API.

>
>     https://wiki.php.net/rfc/expectations
>
> Cheers
> Joe
>

--047d7bd6adce7c7101050f31d703--