> $this->a = require(> 100); This is already valid-ish code ..
On Tue, Feb 10, 2015 at 9:56 AM, Robert Stoll <p...@tutteli.ch> wrote: > We could provide an Invariant class in order to support invariant cases at > least to a certain degree: > http://3v4l.org/vjBRG > > Of course, that does not provide the same support as native invariants but > maybe better than nothing. At least we would have a consistent Invariant > class throughout the code bases. > We could go even further and provide some syntactic sugar in order that > one does not need to write new Invariant(...) as in line 28 -- for instance: > > $this->a = require(> 100); > > which is short for > > $this->a = new Invariant(function($value){return $value > 100;}, '$this->a > > 100'); > > Cheers, > Robert > > > -----Ursprüngliche Nachricht----- > > Von: Dmitry Stogov [mailto:dmi...@zend.com] > > Gesendet: Dienstag, 10. Februar 2015 08:06 > > An: Joe Watkins > > Cc: Yasuo Ohgaki; PHP Internals; Stanislav Malyshev > > Betreff: Re: [PHP-DEV] Design by Contract > > > > good point, but I think we can do nothing about that. > > Anyway, it should be reflected in RFC. > > > > Dmitry. > > > > > > > > On Tue, Feb 10, 2015 at 9:59 AM, Joe Watkins <pthre...@pthreads.org> > wrote: > > > > > I'm not sure we can always enforce invariant contracts ... > > > > > > Evaluating invariant expressions on entry and exit is not enough, > > > since a property can be changed without the use of a method. > > > > > > Can or should, we do anything about that ? > > > > > > This should also be covered in the RFC, I think. > > > > > > Cheers > > > Joe > > > > > > On Tue, Feb 10, 2015 at 6:49 AM, Dmitry Stogov <dmi...@zend.com> > wrote: > > > > > >> Hi, > > >> > > >> can I make some minor correction? > > >> > > >> Thanks. Dmitry. > > >> > > >> > > >> > > >> On Tue, Feb 10, 2015 at 9:25 AM, Yasuo Ohgaki <yohg...@ohgaki.net> > wrote: > > >> > > >>> Hi Dmitry, > > >>> > > >>> On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov <dmi...@zend.com> > wrote: > > >>> > > >>>> On Feb 9, 2015 11:20 PM, "Yasuo Ohgaki" <yohg...@ohgaki.net> wrote: > > >>>> > > > >>>> > Hi Dmitry and Joe, > > >>>> > > > >>>> > On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov <dmi...@zend.com> > > >>>> wrote: > > >>>> >> > > >>>> >> yes. this may work. > > >>>> >> probably better to put it after extends and implements. > > >>>> >> > > >>>> >> > > >>>> >> Dmitry. > > >>>> >> > > >>>> >> On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins > > >>>> >> <pthre...@pthreads.org> > > >>>> wrote: > > >>>> >>> > > >>>> >>> Could this be described as a requirement of the class ? > > >>>> >>> > > >>>> >>> class Mine > > >>>> >>> require(invariant-expr) > > >>>> >>> extends Something > > >>>> >>> implements Someface { > > >>>> >>> > > >>>> >>> public function method($param) : return > > >>>> >>> require(input-expr), > > >>>> >>> return(output-expr) { > > >>>> >>> > > >>>> >>> } > > >>>> >>> } > > >>>> >>> > > >>>> >>> To avoid invariant keyword maybe. > > >>>> > > > >>>> > > > >>>> > This would work. > > >>>> > If users have adopted DbC in some way, 'invariant' may be used > > >>>> already. > > >>>> > > > >>>> > I see two issues. > > >>>> > > > >>>> > Interface works, but most classes are class without interfaces. > > >>>> > Then > > >>>> users have to repeat > > >>>> > require()/return() many times to check class state or have to use > > >>>> interface for DbC. > > >>>> > > > >>>> > > >>>> In D classes may have "invariant" constraints. We may use "require" > > >>>> keyword for it. The constraints ineritance rules and order of calls > > >>>> to constrains must be the same s in D. > > >>>> > > >>>> class Foo { > > >>>> private $sum = 0; > > >>>> require($this->sum >= 0); // invariant constraint will be > > >>>> called before and after every method > > >>>> function add($n) { > > >>>> $this->sum += $n; > > >>>> } > > >>>> } > > >>>> > > >>> > > >>> OK. I'll update the RFC. > > >>> > > >>> > > >>>> > Since compiler does not know a method() is for DbC invariant, it > > >>>> > will > > >>>> be compiled and exists > > >>>> > in production execution. > > >>>> > > > >>>> > Use of interface: > > >>>> > - no additional keyword (pros) > > >>>> > - requires interface for DbC, most classes does not require > > >>>> interface (cons) > > >>>> > - if interface is not used, user has to repeat invariant > > >>>> > conditions > > >>>> over and over (cons) > > >>>> > - requires to define method that should not exist in production > > >>>> (cons) > > >>>> > > >>>> I didn't understand you idea. > > >>>> > > >>> > > >>> Joe's idea was to use Interface for invariant condition grouping. > > >>> If we use your idea, issue is solved. > > >>> > > >>> class Foo { > > >>>> private $sum = 0; > > >>>> require($this->sum >= 0); // invariant constraint will be > > >>>> called before and after every method > > >>>> function add($n) { > > >>>> $this->sum += $n; > > >>>> } > > >>>> } > > >>>> > > >>> Ok. > > >>> > > >>>> > > > >>>> > New keyword: > > >>>> > - does not require interface for efficient definition (pros). > > >>>> > - new keyword (cons) > > >>>> > > > >>>> > It seems we are better to choose proper keyword for 'invariant'. > > >>>> 'invariant' is not common, so 'invariant' > > >>>> > may be good enough choice. Does anyone use 'invariant' as > > >>>> function/method/class/constant names? > > >>>> > If there is better name, suggestion is appreciated. > > >>>> > > > >>>> > On place closure call like javascript is not supported in PHP, > > >>>> > but > > >>>> function works with assert. > > >>>> > > > >>>> > <?php > > >>>> > function foo() { return FALSE; } > > >>>> > assert(foo()); > > >>>> > ?> > > >>>> > PHP Warning: assert(): Assertion failed in - on line 3 > > >>>> > > > >>>> > This wouldn't be changed for require()/return()/invariant()? > > >>>> > > > >>>> > We need a switch to change development/production. I'll use > > >>>> "dbc=On/Off" for now. > > >>>> > If you have any better idea, please let me know. (dbc will be > > >>>> INI_SYSTEM) > > >>>> > > >>>> Check the "expectations" RFC. I think, it's going to be 3 state > > >>>> switch, zero-cost disable, run-time disable, run-time enable. So, > > >>>> it may be INI_ALL, but it won't be possible to switch from/to > zero-cost at run-time. > > >>>> > > >>> > > >>> Ok. > > >>> > > >>>> > > > >>>> > For CLI, there will be no command line switch for dbc. It > > >>>> > executes > > >>>> script production mode by > > >>>> > default. If user needs development mode > > >>>> > > > >>>> > php -d dbc=1 script.php > > >>>> > > > >>>> > should be used. > > >>>> > > > >>>> > > > >>>> > And finally, are we going to allow custom assertion error message? > > >>>> e.g. > > >>>> > > > >>>> > require($a > 0, 'Parameter $a must be positive number'); > > >>>> > > >>>> I think, it may be useful. > > >>>> > > >>> Ok. I'll use it. > > >>> > > >>>> > > > >>>> > Since this contract is definition like "implements"/"extends", we > > >>>> > may > > >>>> not allow > > >>>> > custom error message. I'll write the RFC not to allow custom > > >>>> > error > > >>>> messages unless > > >>>> > you dislike it. > > >>>> > > > >>>> > I think we have enough consensus/information to start writing the > RFC. > > >>>> > If I have any concern, I'll ask here. > > >>>> > > >>>> Ok, go forward :) > > >>>> > > >>> Updated wiki page. > > >>> https://wiki.php.net/rfc/dbc2 > > >>> > > >>> If you would like to change something, please let me know. > > >>> I don't think finished draft at all and I don't mind going back and > > >>> forth. > > >>> > > >>> Regards, > > >>> > > >>> -- > > >>> Yasuo Ohgaki > > >>> yohg...@ohgaki.net > > >>> > > >> > > >> > > > > >
