Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71660
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXa+VdBP+eDmGLYSX+94+fHfmAqASA_3aZOj_JrAVg1fgw@mail.gmail.com>
References: <CAGa2bXa+VdBP+eDmGLYSX+94+fHfmAqASA_3aZOj_JrAVg1fgw@mail.gmail.com>
Date: Tue, 28 Jan 2014 09:36:08 +0100
Message-ID: <CALtuQzAXGFz3MZKbZWMAxLEkvSuNXtnd7wtKQmAaARxCE6p2-w@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2bccaab4a2d04f103b964
Subject: Re: [PHP-DEV] DbC for PHP?
From: krebs.seb@gmail.com (Sebastian Krebs)

--001a11c2bccaab4a2d04f103b964
Content-Type: text/plain; charset=ISO-8859-1

2014-01-28 Yasuo Ohgaki <yohgaki@ohgaki.net>

> Hi all,
>
> I'm wandering if we could have DbC (Design by Contract) for PHP 6.
> http://en.wikipedia.org/wiki/Design_by_contract
>
> There is user land implementation already.
>
> https://gitorious.org/higher-order-php/php-contracts/source/5b0a53b9732f0e4dbe79345212c84c74526def3b
> :
>
> It could be done with dbc mode INI switch as follows.
>
> When dbc=on, automatically includes
>
> include __dbc_ . __SCRIPT_NAME__;
>
>  when a script is loaded. No error if there is not the script.
> When function/method is called
>
> __dbc_pre_. __FUNCTION__() is called before calling function().
> __dbc_post_.___FUNCTION__() is called after function() call.
>
> No error if there is not the function.
>

Couldn't you achieve the same with assert()?


>
> Class methods would be more complex, but basic idea is the same.
> Issue would be what we should do with $this with class methods.
>
> Automatic namespace might be nice to have for both function and class.
>
> When dbc=off, these would be skipped at all.
>
> It does not sacrifice performance at all for production while it could
> catch
> various errors during development. It could do more complex assertion
> than assert() and it could check post condition that is difficult to
> achieve
> by assert(). User could have their own strong type safety as long as they
> have strict input validation. It could be used as complement of annotation.
>
> Just an idea.
> Any comments?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>



-- 
github.com/KingCrunch

--001a11c2bccaab4a2d04f103b964--