Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82242
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbouFXRS+K-AEOBJhWsraQb7Xjh6xe_Gd8N_f3EKsoumw@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<54D7ED22.3080001@gmail.com>
	<CAGa2bXZMmPTT=EgxKiXTbRhDJvd=6UfJ5jJrZwCRvFsnY-D=yQ@mail.gmail.com>
	<CAFp73XuVGRbmUG=ZVecq8=Ms1dN5_SyG6Z1T3JcPoa32QsaY5Q@mail.gmail.com>
	<CAGa2bXZ8p8VibVoZtJ3fOsLbKbzoQ3Fn=5_=Supg_d1y5My4xQ@mail.gmail.com>
	<CAFp73XsArH8SG5T2T7=HaAGUkvAz_P627iSibQfzeFtKyUcoOA@mail.gmail.com>
	<CAGa2bXbouFXRS+K-AEOBJhWsraQb7Xjh6xe_Gd8N_f3EKsoumw@mail.gmail.com>
Date: Mon, 9 Feb 2015 12:40:15 +0400
Message-ID: <CA+9eiLs8wdY-4iOOA0AJDWpK1ymHReR_cCyboFZugsqG3nmRfQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, Alexander Lisachenko <lisachenko.it@gmail.com>, 
	"guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: Joe Watkins <krakjoe@php.net>, Stanislav Malyshev <smalyshev@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf307d048229c4a4050ea3b8b4
Subject: Re: [PHP-DEV] Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--20cf307d048229c4a4050ea3b8b4
Content-Type: text/plain; charset=UTF-8

Hi,

I'll try to answer to all the emails at once.

Personally, I like the D approach more, but doc-comment proposal has its
advantages as well.
The problem that doc-comment solution is external to PHP core.
In my opinion, it should be implemented as a separate preprocessor that
reads doc-comments and generates PHP code with asserts().
I don't see how this may be implemented in PHP core itself, and I most
probably won't be evolved in development of other project.
Something similar was already implemented...
Alexander, could you please send link to implentation/dicumentation and
explain how it works (in few words).

Yasuo, I think you should describe the D proposal as well. I'm not sure if
it should be done in the same RFC (it's already big) or a new one.

Any solution would require zero-cost assert (or similar concept)
implemented in php core.

Thanks. Dmitry.



On Mon, Feb 9, 2015 at 8:52 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Guilherme,
>
> On Mon, Feb 9, 2015 at 1:44 PM, guilhermeblanco@gmail.com <
> guilhermeblanco@gmail.com> wrote:
>
>> Class invariants could be done as this example:
>>
>> class Foo {
>>     private function isValidState() {
>>         // Checks class's state and returns boolean
>>     }
>>
>>     public function doSomething($args) {
>>         // Some complex operation over Foo instance using $args
>>         // then...
>>
>>         assert $this->isValidState(): $this; // it would call
>> Foo::__toString() for AssertionError message
>>     }
>> }
>>
>> Another example of pre and post conditions:
>>
>> function foo($number) {
>>     // pre-condition
>>     assert is_numeric($number): '...';
>>
>>     // Some expensive operation creating $value as response
>>
>>     // post-condition
>>     assert someCheckWith($value): '...';
>>     return $value;
>> }
>>
>> A good explanation about use-cases can be found here
>> http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#class-invariants
>>
>
> Thank you for the info.
>
> I had this syntax in mind.
>
> class Foo {
>    __invariant() {
>       // Ignored for production.
>       // Check class state, every method calls invoke this method
> before/after except
>       //  __construct()/__wakeup()/__set_state() - after only
>       //  __destruct() - before only
>    }
> }
>
> // Framework developer shouldn't use this. Leave this function for app
> developers.
> function __invariant() {
>   // Ignored for production.
>   // Invariant conditions of functions invoked for every function calls
>   // to check app state. e.g. global vars,etc
> }
>
> __invariant() has similar issue as __autoload(), we may be better to
> provide generic registration
> method.
>
> Just my initial thought for discussion.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

--20cf307d048229c4a4050ea3b8b4--