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
>>>
>>
>>
>
