Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81958
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXYQotZvbrn0Zj_VM8FOs_HU16kyuWggStSJ38a7fRR7CQ@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<01d601d04146$6fbda4c0$4f38ee40$@tekwire.net>
	<CA+9eiLvQroYuUW_dVr+r5c=O=1aQ3upfahVUd1e-9qpLQRrxUw@mail.gmail.com>
	<020c01d0414b$2c3a1120$84ae3360$@tekwire.net>
	<CAEZPtU41ud0JSzfc6axnzdKCNJ48-LBCx=zuiFVpQ1mNdTK-kA@mail.gmail.com>
	<CAGa2bXZcTGdB6=iTJxnfkCm6dkUa=dHrsGKcofG3pSTftafRzg@mail.gmail.com>
	<023201d0415e$5731d800$05958800$@tekwire.net>
	<CAGa2bXZYvt5U644Q7+_Tr9o7=1X9svWK8OQEK4s06js9GGngyA@mail.gmail.com>
	<CAGa2bXYQotZvbrn0Zj_VM8FOs_HU16kyuWggStSJ38a7fRR7CQ@mail.gmail.com>
Date: Thu, 5 Feb 2015 22:58:46 +0400
Message-ID: <CA+9eiLtD2o3FVQJwS9TrVfRCy9H4YtJG3fubq+KBwVPXZ+wjWg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>, 
	Pierre Joye <pierre.php@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3ef80cd6dc1050e5be41e
Subject: Re: [PHP-DEV] Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--001a11c3ef80cd6dc1050e5be41e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If we allow any statements in require/ensure, then we should use {} instead
of()

function foo($a, $b)
    reuire {
        ...
    }
    ensure($ret) {
       ...
    }
{
}

my idea was to restrict constraint code to expression.
in this case () would be enough.
it should be possible to use few constraint expressions.
we may also add error messages like in assert().

function add($a, $b)
  require(is_numeric($a) && $a >=3D 0, "some error message")
  require(is_numerc($b) && $b >=3D 0, "another error message")
  ensure($ret >=3D 0, "yet another error message)
{
  return $a + $b;
}

both proposals may work, of course.

I don't think we should chose "right" approach right now.
It's better to collect few possible solutions e.g. statements, expressions,
doc-comments, attributes...
then describe their pros and cons to select the best one

Thanks. Dmitry.

Thanks. Dmitry.

On Thu, Feb 5, 2015 at 8:54 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Francois,
>
> On Fri, Feb 6, 2015 at 1:18 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>>
>> On Fri, Feb 6, 2015 at 1:11 AM, Fran=C3=A7ois Laupretre <francois@tekwir=
e.net>
>> wrote:
>>
>>> > De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo
>>> Ohgaki
>>>
>>> > We don't have to integrate DbC into phpdoc. phpdoc may have
>>> integration of new DbC syntax.
>>> > I think it's helpful even if phpdoc copies post/pre condition as
>>> document.
>>> >
>>> > There are too many possibility for DbC syntax.
>>> > We are better to choose something in common among languages.
>>>
>>> No. The more I detail the concept, the more I read alternative
>>> proposals, the more I consider extending phpdoc is the best solution. A=
s I
>>> explain in the RFC, both concepts are closely related, and that's the o=
nly
>>> solution I've seen so far that preserves BC. I could add that it propos=
es a
>>> solution to issues not even detected nor discussed in alternative
>>> proposals, like the syntax for return value, separate check for argumen=
ts
>>> returned by ref, built-in type checks, etc. Before we choose an alterna=
tive
>>> syntax, I think we should have good reasons, not 'Hey, that's how it's =
done
>>> in D !'. If there's a good reason to copy D or Eiffel syntax, let's ado=
pt
>>> it, but I haven't read any good reason so far. And D is not so widely u=
sed
>>> so there's no user habit. We can copy the concept without copying the
>>> syntax.
>>>
>>> I think we're going too fast here. Before giving up and switching to
>>> another syntax, can you give me a little time to present what I have in
>>> mind. I started writing it yesterday evening and it will be ready
>>> tomorrow morning (UTC). Then, we can make a decision.
>>>
>>
>> I didn't notice you have updated the RFC sorry. Sure, I'll read it and
>> respond.
>>
>
> https://wiki.php.net/rfc/dbc
>
> Thank you for your time. It's based on annotation approach. This kind of
> implementation requires a lot of work...
>
> I have more simpler approach in my mind based on current PHP language
> not to invent new language. I'll use syntax something similar to Dmitry
> proposed.
>
> Let me explain my original thought.
>
> Since we have reserved __functionname(), __some_functioname() should not
> have
> BC issues.
> ----------------
> function foo($param)
> require ( // Compiled as __require_foo($param)
>   // Any PHP code is allowed and works just like PHP function.
>   // Abuse is possible. Users have freedom shoot their own foot.
>   assert('is_string($param');
>   if (strlen($param) > 100) {
>      echo "String is more than 100\n";
>      return FALSE; // return value is ignored.
>   }
> )
> ensure ( // Compiled as __ensure_foo($__return_value)
>   // Same as require. Any PHP code
>   assert('is_int($__return_value)'); // $__return_value is the return val=
ue
>   assert($__return_value > 0);
> )
> invariant ( // Check conditions always true. It may be __invariant_foo()
>   // Question is should this have foo() scope?
>   // Same as require/ensure. Any PHP code.
>   // invariant() exists not to repeat require()/ensure()
> )
> // Function body
> {
>   // BODY
> }
> ----------------------
>
> Zend engine has 2 execute()
>
>  - execute()  -  Just execute foo()
>  - execute_dev() - Call functions as follows
>
> __require_foo($param)
> __invariant()
> foo()
> __invariant()
> __ensure_foo($__return_value)
>
>
> With this approach, parser and compiler needs little modification and
> execute_dev() can handle additional functions while execute() only
> executes foo(). execute_dev() is simple because it just calls plain PHP
> functions if they exists.
>
> Is there is syntax error or assertion error. Error messages look like
>
> PHP Warning:  assert(): asdfasdf failed in __require_foo() on line 2
>
> This is simple yet useful/easy to use/powerful/flexible/fast.
> Any checks can be done with PHP syntax. I think assert() should be used
> usually, though.
>
> I thought to use require{} rather than require() because {} seemed
> natural for function.
>
> This is my thought. It's almost D.
> I don't know about AST much, so AST may be better/easier than having
> 2 execute().
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
>

--001a11c3ef80cd6dc1050e5be41e--