Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81952
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXZYvt5U644Q7+_Tr9o7=1X9svWK8OQEK4s06js9GGngyA@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>
Date: Fri, 6 Feb 2015 02:54:27 +0900
Message-ID: <CAGa2bXYQotZvbrn0Zj_VM8FOs_HU16kyuWggStSJ38a7fRR7CQ@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>
Cc: Pierre Joye <pierre.php@gmail.com>, PHP internals <internals@lists.php.net>, 
	Dmitry Stogov <dmitry@zend.com>
Content-Type: multipart/alternative; boundary=001a11c2cc9a1ee0c5050e5b0157
Subject: Re: [PHP-DEV] Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c2cc9a1ee0c5050e5b0157
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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@tekwire=
.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 integratio=
n
>> 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. As I explain =
in
>> the RFC, both concepts are closely related, and that's the only solution
>> I've seen so far that preserves BC. I could add that it proposes a solut=
ion
>> to issues not even detected nor discussed in alternative proposals, like
>> the syntax for return value, separate check for arguments returned by re=
f,
>> built-in type checks, etc. Before we choose an alternative syntax, I thi=
nk
>> 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 adopt it, but I
>> haven't read any good reason so far. And D is not so widely used so ther=
e'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 value
  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

--001a11c2cc9a1ee0c5050e5b0157--