Re: Design by Contract

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 >