Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry,

On Wed, Mar 4, 2015 at 5:35 PM, Dmitry Stogov  wrote:

> assert() is not for DbC. It''s useful by it's own. However, new zero-cost
> assert() implementation should be reused for true DbC.


I fully agree.
I cannot wait to have it.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

On Tue, Mar 3, 2015 at 10:04 PM, Yasuo Ohgaki  wrote:

> Hi Dmitry,
>
> On Mon, Mar 2, 2015 at 4:20 PM, Dmitry Stogov  wrote:
>
>> It may be to late for 7.0.
>>
>
> I feel the same way. It may be better to try add it with 7.x.
>
>
>> Also Alexander liked to to add another proposal, but I saw only
>> pre-required one(s)
>> Anyway, it's not a big problem to vote now.
>> I may take care about implementation for https://wiki.php.net/rfc/dbc2
>> (but only if it wins).
>
>
> Thank you.
> The proposal would not break existing code as it does not reserve new
> keywords.
> We may try to add later on. Assert only DbC is messy and harder to
> maintain,
> but it's good start.
>

assert() is not for DbC. It''s useful by it's own. However, new zero-cost
assert() implementation should be reused for true DbC.

Thanks. Dmitry.



>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry,

On Mon, Mar 2, 2015 at 4:20 PM, Dmitry Stogov  wrote:

> It may be to late for 7.0.
>

I feel the same way. It may be better to try add it with 7.x.


> Also Alexander liked to to add another proposal, but I saw only
> pre-required one(s)
> Anyway, it's not a big problem to vote now.
> I may take care about implementation for https://wiki.php.net/rfc/dbc2
> (but only if it wins).


Thank you.
The proposal would not break existing code as it does not reserve new
keywords.
We may try to add later on. Assert only DbC is messy and harder to
maintain,
but it's good start.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

Hi Yasuo,

It may be to late for 7.0.
Also Alexander liked to to add another proposal, but I saw only
pre-required one(s)
Anyway, it's not a big problem to vote now.
I may take care about implementation for https://wiki.php.net/rfc/dbc2 (but
only if it wins).

Thanks. Dmitry.

On Sun, Mar 1, 2015 at 6:46 AM, Yasuo Ohgaki  wrote:

> Hi all,
>
> I made vote only RFC and started discussion for voting
> https://wiki.php.net/rfc/introduce_design_by_contract
> Please feel free to correct/improve it.
>
> I added note to our RFCs
>
> https://wiki.php.net/rfc/dbc
> ---
> This RFC is part of “Design by Contract Introduction” RFC
>
> https://wiki.php.net/rfc/introduce_design_by_contract
> There is alternative implementation proposal by “Definition”
>
> https://wiki.php.net/rfc/dbc2
> 
>
> https://wiki.php.net/rfc/dbc2
> 
> This RFC is part of “Design by Contract Introduction” RFC
>
> https://wiki.php.net/rfc/introduce_design_by_contract
> This RFC is an alternative approach to “Native DbC support” RFC.
>
> http://wiki.php.net/rfc/dbc
> 
>
> I understand there are things to resolve, but RFCs are good enough to
> start discussions. I'll post discussion mail shortly. If you find anything,
> have any comments or any show stopper, please let me know.
>
> Thank you!
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi all,

I made vote only RFC and started discussion for voting
https://wiki.php.net/rfc/introduce_design_by_contract
Please feel free to correct/improve it.

I added note to our RFCs

https://wiki.php.net/rfc/dbc
---
This RFC is part of “Design by Contract Introduction” RFC

https://wiki.php.net/rfc/introduce_design_by_contract
There is alternative implementation proposal by “Definition”

https://wiki.php.net/rfc/dbc2


https://wiki.php.net/rfc/dbc2

This RFC is part of “Design by Contract Introduction” RFC

https://wiki.php.net/rfc/introduce_design_by_contract
This RFC is an alternative approach to “Native DbC support” RFC.

http://wiki.php.net/rfc/dbc


I understand there are things to resolve, but RFCs are good enough to
start discussions. I'll post discussion mail shortly. If you find anything,
have any comments or any show stopper, please let me know.

Thank you!

--
Yasuo Ohgaki
yohg...@ohgaki.net

RE: [PHP-DEV] Design by Contract

[François Laupretre]

Hi Yasuo,

 

I just suggest you add the following notice text at the beginning of your RFC :

 

An alternative ‘Design by Contract’ RFC exists (https://wiki.php.net/rfc/dbc). 
It was started by François Laupretre, is based on annotations, and proposes an 
alternative syntax to add contract support to PHP. The RFC is currently 
suspended, waiting for final decisions about scalar type hinting, and won’t be 
proposed for an implementation in 7.0.

 

That’s just a suggestion. Anyway, go on with the discussion about your RFC. 
Don’t wait for me, as I won’t have time to propose it for 7.0. Again, if you 
want to be *really* fair, just insert the notice above or something similar at 
the top of your RFC. So people will have access to all available information 
before they make their decision.

 

Thanks

 

François

 

De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Envoyé : mercredi 25 février 2015 22:32
À : francois
Cc : Dmitry Stogov; Joe Watkins; Stanislav Malyshev; PHP Internals
Objet : Re: [PHP-DEV] Design by Contract

 

Hi all,

 

I would like to start [DISCUSSION] for this RFC.

RFC may needs update, but these changes can be done during the discussion also.

 

Any comments for staring discussion?

 

P.S. I'll prepare simple "Vote Only" RFC for 2 RFCs. Please feel free to 
change/improve it.

 




--
Yasuo Ohgaki 
yohg...@ohgaki.net

 

On Mon, Feb 16, 2015 at 2:56 PM, Yasuo Ohgaki  wrote:

Hi Francois,


On Mon, Feb 16, 2015 at 8:08 AM, François Laupretre  wrote:
>
> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
> >
> > D resolves that if parameter is contract or not at compile time and checks 
> > it if method
> > is overriding parent's method. If method is overridden, D just ignores 
> > contract.
>
> That's true for pre-conditions, but that's not the way D handles 
> post-conditions.
>
> >>> The same rule for class applies to interfaces.
> >>
> >> ?? I don't understand.
> >
> >Interface may have contracts just like class.
>
> OK, but when do you check interface conditions ? And how do you deal with 
> interface (multiple) inheritance ?

 

Simply check all contracts on method calls.

If property check (invariant) could be issue, class designer should use 
document for proper 

property management rather than contracts. Or we may drop invariant support for 
interface.


>
> >>> We cannot ignore parent class invariants. If developer violate parent
> >>> property restrictions,
> >>> it's violation of parent class type and this must be forbidden. It's
> >>> checked by invariant contract.
> >>
> >> I agree.
> >
> > We have(had) weak type system. Choosing right type system for PHP would be 
> > very hard.
> > I didn't intended to bring this topic... Could we introduce simple "Design 
> > by Contract"
> > concept?  Or are we going to discuss right type system for PHP?
>
> Sure, but are you realizing that you're discarding your own statement, not 
> mine ?

 

Type safety consideration was not intended at first.

So I don't have problem with disregarding type safety.

We may introduce type safety/system when we have template, strict types and/or 
overloading, for example.


> I never told about the PHP type system because I don't understand what types 
> have to do here. So, yes, I don't care about the PHP type system and that's 
> not the subject. We are discussing about PHP conditions and when they are 
> evaluated, that's all.
>
> And, sorry about that, but could you stop sending html messages ? It makes 
> replies much harder.

It seems gmail does not have the option, but I can only remove text formatting 
manually.
Does this mail seems OK to you?

 

Anyway, how about not to consider type safety too much now? and

concentrate to introduce simple DbC?

We may have option for strict type in the future for whatever type system

we introduce at that time.


Regards,



--
Yasuo Ohgaki 
yohg...@ohgaki.net

 

 

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi all,

I would like to start [DISCUSSION] for this RFC.
RFC may needs update, but these changes can be done during the discussion
also.

Any comments for staring discussion?

P.S. I'll prepare simple "Vote Only" RFC for 2 RFCs. Please feel free to
change/improve it.


--
Yasuo Ohgaki
yohg...@ohgaki.net

On Mon, Feb 16, 2015 at 2:56 PM, Yasuo Ohgaki  wrote:

> Hi Francois,
>
> On Mon, Feb 16, 2015 at 8:08 AM, François Laupretre 
> wrote:
> >
> > > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
> Ohgaki
> > >
> > > D resolves that if parameter is contract or not at compile time and
> checks it if method
> > > is overriding parent's method. If method is overridden, D just ignores
> contract.
> >
> > That's true for pre-conditions, but that's not the way D handles
> post-conditions.
> >
> > >>> The same rule for class applies to interfaces.
> > >>
> > >> ?? I don't understand.
> > >
> > >Interface may have contracts just like class.
> >
> > OK, but when do you check interface conditions ? And how do you deal
> with interface (multiple) inheritance ?
>
> Simply check all contracts on method calls.
> If property check (invariant) could be issue, class designer should use
> document for proper
> property management rather than contracts. Or we may drop invariant
> support for interface.
>
> >
> > >>> We cannot ignore parent class invariants. If developer violate parent
> > >>> property restrictions,
> > >>> it's violation of parent class type and this must be forbidden. It's
> > >>> checked by invariant contract.
> > >>
> > >> I agree.
> > >
> > > We have(had) weak type system. Choosing right type system for PHP
> would be very hard.
> > > I didn't intended to bring this topic... Could we introduce simple
> "Design by Contract"
> > > concept?  Or are we going to discuss right type system for PHP?
> >
> > Sure, but are you realizing that you're discarding your own statement,
> not mine ?
>
> Type safety consideration was not intended at first.
> So I don't have problem with disregarding type safety.
> We may introduce type safety/system when we have template, strict types
> and/or overloading, for example.
>
> > I never told about the PHP type system because I don't understand what
> types have to do here. So, yes, I don't care about the PHP type system and
> that's not the subject. We are discussing about PHP conditions and when
> they are evaluated, that's all.
> >
> > And, sorry about that, but could you stop sending html messages ? It
> makes replies much harder.
>
> It seems gmail does not have the option, but I can only remove text
> formatting manually.
> Does this mail seems OK to you?
>
> Anyway, how about not to consider type safety too much now? and
> concentrate to introduce simple DbC?
> We may have option for strict type in the future for whatever type system
> we introduce at that time.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Francois,

On Mon, Feb 16, 2015 at 8:08 AM, François Laupretre 
wrote:
>
> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
> >
> > D resolves that if parameter is contract or not at compile time and
checks it if method
> > is overriding parent's method. If method is overridden, D just ignores
contract.
>
> That's true for pre-conditions, but that's not the way D handles
post-conditions.
>
> >>> The same rule for class applies to interfaces.
> >>
> >> ?? I don't understand.
> >
> >Interface may have contracts just like class.
>
> OK, but when do you check interface conditions ? And how do you deal with
interface (multiple) inheritance ?

Simply check all contracts on method calls.
If property check (invariant) could be issue, class designer should use
document for proper
property management rather than contracts. Or we may drop invariant support
for interface.

>
> >>> We cannot ignore parent class invariants. If developer violate parent
> >>> property restrictions,
> >>> it's violation of parent class type and this must be forbidden. It's
> >>> checked by invariant contract.
> >>
> >> I agree.
> >
> > We have(had) weak type system. Choosing right type system for PHP would
be very hard.
> > I didn't intended to bring this topic... Could we introduce simple
"Design by Contract"
> > concept?  Or are we going to discuss right type system for PHP?
>
> Sure, but are you realizing that you're discarding your own statement,
not mine ?

Type safety consideration was not intended at first.
So I don't have problem with disregarding type safety.
We may introduce type safety/system when we have template, strict types
and/or overloading, for example.

> I never told about the PHP type system because I don't understand what
types have to do here. So, yes, I don't care about the PHP type system and
that's not the subject. We are discussing about PHP conditions and when
they are evaluated, that's all.
>
> And, sorry about that, but could you stop sending html messages ? It
makes replies much harder.

It seems gmail does not have the option, but I can only remove text
formatting manually.
Does this mail seems OK to you?

Anyway, how about not to consider type safety too much now? and
concentrate to introduce simple DbC?
We may have option for strict type in the future for whatever type system
we introduce at that time.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

RE: [PHP-DEV] Design by Contract

[François Laupretre]

> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
> D resolves that if parameter is contract or not at compile time and checks it 
> if method
> is overriding parent's method. If method is overridden, D just ignores 
> contract.

That's true for pre-conditions, but that's not the way D handles 
post-conditions.

>>> The same rule for class applies to interfaces.
>>
>> ?? I don't understand.
>
>Interface may have contracts just like class.

OK, but when do you check interface conditions ? And how do you deal with 
interface (multiple) inheritance ?

>>> We cannot ignore parent class invariants. If developer violate parent
>>> property restrictions,
>>> it's violation of parent class type and this must be forbidden. It's
>>> checked by invariant contract.
>>
>> I agree.
>
> We have(had) weak type system. Choosing right type system for PHP would be 
> very hard.
> I didn't intended to bring this topic... Could we introduce simple "Design by 
> Contract"
> concept?  Or are we going to discuss right type system for PHP?

Sure, but are you realizing that you're discarding your own statement, not mine 
?

I never told about the PHP type system because I don't understand what types 
have to do here. So, yes, I don't care about the PHP type system and that's not 
the subject. We are discussing about PHP conditions and when they are 
evaluated, that's all.

And, sorry about that, but could you stop sending html messages ? It makes 
replies much harder.

Regards

François



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Francois,

On Mon, Feb 16, 2015 at 1:08 AM, François Laupretre 
wrote:
>
> > Now I understand what you are discussing. Since we may have stricter
> > typing, we probably better
> > to consider type safety theory even if PHP is weakly typed.
>
> I am not sure it was about types, it was about conditions...

Type theory is not too complex, but it's contradictory against common
sense.
I guess it's one of the reason (or main reason) why D folks dropped class
invariant
support even if it's very useful.

Choosing right type system is not simple. Not all languages has the same.

http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)

As you can see, languages has different type system.


 Argument type  Return type
C++ (since 1998), Java (since J2SE 5.0), Scala, D  Invariant
 Covariant
C#
InvariantInvariant
Sather
Contravariant Covariant
Eiffel
Covariant   Covariant

It seems how we should/are going to handle types in detail. (Or we may say
"PHP is weakly typed, let's forget about types for DbC for now and stick to
basic DbC concept only.")

> > Pre/Postconditions should be checked only when parent method is called.
> > That's what Eiffel does.
> > Eiffel does not allow method overriding. Therefore, pre/postconditions
of
> > methods (not invariants.
> > Invariants inherited implicitly(automatically) both Eiffel and D are
> > evaluated except certain
> > methods) cannot be evaluated automatically unless parent method is
called.
>
> I agree for pre-conditions, but not sure for post-conditions.
>
>
> > Since children's method may have whole different way of handing
> > parameters,
> > including swapping parameter order, adding/removing parameters, etc.
> > Parameters cannot be checked automatically unless we have some kind of
> > binding system that bind child parameter to parent parameter. Even if we
> > have
> > it, parameter for parents may be generated in function body. It cannot
be
> > perfect.
>
> I hadn't thought about this. Parent and derived methods can have
different signatures.
>
> So, you mean we cannot inherit pre/post-conditions in any way.
>
> But what about interfaces, as the signature matches there ? The interface
case is complex, as a class can implement more than one interface and
interfaces can be extended, providing the same potential problems as
multiple inheritance.
>
> The parent's post-conditions should be checked too, but in the parent
scope, which is probably impossible (using parent argument names). To solve
this, we can split post-conditions to two sets : those which deal with the
return type and value only, and those that check other conditions (passed
by ref args, for instance). Then, the parent's post-conditions which deal
with return value only can be checked when the derived methods exit.


D resolves that if parameter is contract or not at compile time and checks
it if method
is overriding parent's method. If method is overridden, D just ignores
contract. In short,
D does complex analysis during compilation.

Work around of this is simple, just call parent method using super. e.g.

/* Not D syntax */
function foo() {
   super.foo();
}

If parent method is called, both child and parent contract is evaluated.
(With Eiffel, rename parent method and call it optionally.)

PHP's default could be this way and this is what I thought originally. This
is
simple and expected behavior for most people. PHP is weakly typed, so
it's enough. (I might have to say it was)

> > Basic rule is we shouldn't be able to modify parent contracts(invariant,
> > methods pre/postconditions).
> > If we can change it, it's the same as changing type.  Your discussion
> > applies to invariant and this
> > is what you write, I suppose.
>
> I am not sure I understand what you mean with 'modify parent contract'.
If you mean that we must apply total inheritance for invariants, I agree.

D disallow modifying parent's method contract when method is overridden
unless child method call super.parentMethod().

Eiffel is even stricter, it disallows overriding parent. It only allows to
remove
or rename parent's method.

> > The same rule for class applies to interfaces.
>
> ?? I don't understand.

Interface may have contracts just like class.

>
>
> > We cannot ignore parent class invariants. If developer violate parent
> > property restrictions,
> > it's violation of parent class type and this must be forbidden. It's
> > checked by invariant contract.
>
> I agree.

We have(had) weak type system. Choosing right type system for PHP would be
very hard.
I didn't intended to bring this topic... Could we introduce simple "Design
by Contract"
concept?  Or are we going to discuss right type system for PHP?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

>  - Consider introduction of static require() as class invariant for static
> methods
>

invariant contacts are executed in object methods. I meant adding "static
invariant" to be executed on static methods.
but I think we don't need them at this point.


>
> I probably don't understand the idea correctly. Could you give some
> explanations?
>
>  - Need to discuss syntax
>
> There were many ideas for possible syntaxes, I prefer current simple
> syntax.
> Syntax is not my priority. I don't mind require{assert();},
> return{assert();}, etc.
> Since "error message" can be added and any expression is allowed, writing
> contracts
> as code may be better. We are better to avoid new keyword whenever it's
> possible.
>
>  - How to manage votes for 2 RFCs
>
> Both RFCs are large enough. How about make vote only RFC
> https://wiki.php.net/rfc/dbc_vote
>  - Explain what is DbC.
>  - Choose "Introduce Native DbC for PHP - Yes or No"
>  - For people voted for Yes, "Annotation or Code" refer
>links to https://wiki.php.net/rfc/dbc, https://wiki.php.net/rfc/dbc2
>   - Choose "Annotation or Code"
>
>
Sounds good. Alexander should provide one more proposal based on
annotations or attributes.


>
> ==Annotation DbC Implementation==
> Dmitry, I guess it wouldn't be too hard for you to implement this RFC. How
> about annotation
> version? Can it be implemented with reasonable amount of efforts?
>

any implementation of DbC is going to be not trivial...

Thanks. Dmitry.


>
>
> Thank you all those who are contributed discussion!
> I hope you choose to have DbC support. DbC helps to achieve
> "strict/precise development"
> and "maximum performance in production" at the same time.
>
> Regards,
>
> P.S. It takes time to get used to new syntax. We may be better try to
> expose new syntax
> as much as possible. i.e. Put new syntax in mails whenever possible.
>
> Native DbC support syntax:
> class Child {
> require($this->age < 18); // Invariant (Class state condition)
>
> public function someMethod($input)
> require(somethingAbout($input)) // Precondition
> return($ret, somethingReturn($ret)) // Postcondition
> {
> /* Great! We are certain that caller satisfy precondition, return
>appropriate return value and have proper class state! */
> }
> }
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>
>

RE: [PHP-DEV] Design by Contract

[François Laupretre]

Hi Yasuo,
> 
> Now I understand what you are discussing. Since we may have stricter
> typing, we probably better
> to consider type safety theory even if PHP is weakly typed.

I am not sure it was about types, it was about conditions...

> Pre/Postconditions should be checked only when parent method is called.
> That's what Eiffel does.
> Eiffel does not allow method overriding. Therefore, pre/postconditions of
> methods (not invariants.
> Invariants inherited implicitly(automatically) both Eiffel and D are
> evaluated except certain
> methods) cannot be evaluated automatically unless parent method is called.

I agree for pre-conditions, but not sure for post-conditions.

> Since children's method may have whole different way of handing
> parameters,
> including swapping parameter order, adding/removing parameters, etc.
> Parameters cannot be checked automatically unless we have some kind of
> binding system that bind child parameter to parent parameter. Even if we
> have
> it, parameter for parents may be generated in function body. It cannot be
> perfect.

I hadn't thought about this. Parent and derived methods can have different 
signatures.

So, you mean we cannot inherit pre/post-conditions in any way.

But what about interfaces, as the signature matches there ? The interface case 
is complex, as a class can implement more than one interface and interfaces can 
be extended, providing the same potential problems as multiple inheritance.

The parent's post-conditions should be checked too, but in the parent scope, 
which is probably impossible (using parent argument names). To solve this, we 
can split post-conditions to two sets : those which deal with the return type 
and value only, and those that check other conditions (passed by ref args, for 
instance). Then, the parent's post-conditions which deal with return value only 
can be checked when the derived methods exit.

> Basic rule is we shouldn't be able to modify parent contracts(invariant,
> methods pre/postconditions).
> If we can change it, it's the same as changing type.  Your discussion
> applies to invariant and this
> is what you write, I suppose.

I am not sure I understand what you mean with 'modify parent contract'. If you 
mean that we must apply total inheritance for invariants, I agree.

> The same rule for class applies to interfaces.

?? I don't understand.

> We cannot ignore parent class invariants. If developer violate parent
> property restrictions,
> it's violation of parent class type and this must be forbidden. It's
> checked by invariant contract.

I agree.

Regards

François



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Design by Contract

[François Laupretre]

> De : Robert Stoll [mailto:p...@tutteli.ch]
>
> The theory is actually quite simple. Roughly it says that if you use a type 
> hint
> of a certain class then you can rely on all pre/post-conditions of this class
> even if a sub-class is passed. Hence the sub-class cannot have more restrict
> conditions.

> I guess from the example above it should be clear why D has implemented it
> this way

OK. Thanks for your explanations.

What I meant is that, while I understand the theory, I don't understand the 
reason *why* it must be done this way.

An additional point is that, IMO, It is impossible for a software to enforce 
the theory and check that a set of conditions is more or less restrictive than 
another one, except analyzing them, which is far beyond our possibilities. So, 
IMO, we can just give it as a convention, which is quite poor. That's why I 
preferred to use another logic. But I would like to know if it won't bring 
other problems later.

Regards

François


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

On Sun, Feb 15, 2015 at 8:17 AM, Yasuo Ohgaki  wrote:

> I wrote simple D program "sample.d" to play with. Install D, then
>
> dmd sample.d && ./sample
>
> sample.d
> import std.stdio;
>
> class A {
> int x = 1;
> int y = 2;
>
>  public:
> void set (int x, int y)
> in {
> assert(x > 0);
> assert(y > 0);
> }
> body {
> this.x = x;
> this.y = y;
> }
>  int mul()
> out (ret) {
> assert(ret > 0);
> }
> body {
> return x * y;
> }
>
> invariant {
> assert(this.x > 0);
> assert(this.y > 0);
> }
> }
>
> class B : A {
> int a;
> int b;
>  override void set (int a, int b)
> in {
> assert(a > 4);
> assert(b > 2);
> }
> body {
> this.a = a;
> this.b = b;
> }
>  override int mul()
> out (ret) {
> assert(ret > 4);
> }
> body {
> return a * b;
> }
>
> invariant {
> assert(this.x > 0);
> assert(this.y > 0);
> }
> }
>
> class C : A {
> override void set (int x, int y)
> in {
> // Cannot work with override
> assert(x > -4);
> assert(y > -2);
> }
> body {
> this.x = x;
> this.y = y;
> }
>  override int mul()
> out (ret) {
> assert(ret > -4);
> }
> body {
> return x * y;
> }
>
> // This cannot work. Less restrictive than parent
> invariant {
> assert(this.x > -4);
> assert(this.y > -2);
> }
> }
>
>
> void main()
> {
> A a = new A;
> B b = new B;
> C c = new C;
> a.set(4,2);
> writeln("Ans: ", a.mul());
> // -1 is invalid
> //a.set(-1, 0); core.exception.AssertError@sample.d(10): Assertion failure
>
> b.set(5,3); // Fine with B. B is different type.
> writeln("Ans: ", b.mul());
> }
> =
>
>
> As you can see, D has type safety by contracts and does non-intuitive
> checks.
> Question is "Does PHP need this kind of type safety?"
>
> I totally agree strict type safety is good for writing correct programs,
> BTW.
> D has type safety feature since it has strong type. If PHP is going to be
> strongly typed language as scalar type hint RFC, and might be stronger
> type than now. We may consider stricter types later. It's not just time
> for it. IMHO.
> PHP may be extended to check contracts like D when
> declare('strict_types'=1).
>


I used latest D rpm package for CentOS/Fedore x86_64 from
http://dlang.org/download.html
It seems invariant() is removed from latest D, but the package can use
invariant().

You may get errors if you use real latest D.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi all,

On Sun, Feb 15, 2015 at 8:25 AM, Yasuo Ohgaki  wrote:

> Both D and Eiffel has way to get around it.
> As I mentioned in previous mails, PHP may be get around with it by default
> because it's the nature of PHP. PHP may be extended to follow type theory
> in the future when strict_types is enabled.
>

To have strong types, PHP programs would be "compiled" programs since
type safety should be resolved at compile time.

Current PHP even allows to replace base class at runtime. e.g.

if ($some_flag) {
  require('A.php'); // Load A class for this
} else {
  require('A.php'); // Load different A class for this
}

This kind of code cannot exist in strongly type world.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Robert,

On Sun, Feb 15, 2015 at 8:14 AM, Robert Stoll  wrote:

> I think you misunderstood me, I did not have any questions, I merely
> wanted to explain to François what LSP means, but thanks anyway :)


I understood. You are correct.

Both D and Eiffel has way to get around it.
As I mentioned in previous mails, PHP may be get around with it by default
because it's the nature of PHP. PHP may be extended to follow type theory
in the future when strict_types is enabled.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi all,

On Sun, Feb 15, 2015 at 7:53 AM, Yasuo Ohgaki  wrote:

> On Sat, Feb 14, 2015 at 8:06 PM, Robert Stoll  wrote:
>
>> The theory is actually quite simple. Roughly it says that if you use a
>> type hint of a certain class then you can rely on all pre/post-conditions
>> of this class even if a sub-class is passed. Hence the sub-class cannot
>> have more restrict conditions. Consider the following (no longer sure which
>> syntax is the one you intend to use, so I just use pre and post):
>>
>> class A{
>>   function foo($x){
>>  pre($x > 100);
>>   }
>> }
>>
>> class B extends A{
>>   function foo($x){
>> pre($x > 50); // less restrictive, that's fine
>>   }
>> }
>>
>> class C{
>>   function foo($x){
>> pre($x > 150); //more restrictive that's not allowed
>>   }
>> }
>>
>> function foo(A $a){
>>   $a->foo(101); // that is ok as long as LSP is not violated
>> }
>>
>> foo(new A()); //that's fine
>> foo(new B()); //fine as well
>> foo(new C()); //nope, C violates LSP and thus will result in an error
>>
>
> Correct. D does not allow to change parents contract. D does fancy check
> for "overridden" methods
> so that child cannot change parent behavior. I agree this is correct for
> type safety.
>
> Since D is strongly typed, D has "overloading" and D user can get around
> with the previous restriction
> easily.
> e.g. foo(x, y) in class B will ignore A::foo contract at all. Same applies
> to type difference, since
> this is what "overloading" is.
>
> PHP is weakly typed. There is no point follow D principle for "overridden"
> methods because PHP type
> is weak and PHP does not have "overloading".
>
> I think this answers to your question.
>
> Regards,
>
> P.S. Are we really going to consider strict type safety for PHP??
>

I wrote simple D program "sample.d" to play with. Install D, then

dmd sample.d && ./sample

sample.d
import std.stdio;

class A {
int x = 1;
int y = 2;

 public:
void set (int x, int y)
in {
assert(x > 0);
assert(y > 0);
}
body {
this.x = x;
this.y = y;
}
 int mul()
out (ret) {
assert(ret > 0);
}
body {
return x * y;
}

invariant {
assert(this.x > 0);
assert(this.y > 0);
}
}

class B : A {
int a;
int b;
 override void set (int a, int b)
in {
assert(a > 4);
assert(b > 2);
}
body {
this.a = a;
this.b = b;
}
 override int mul()
out (ret) {
assert(ret > 4);
}
body {
return a * b;
}

invariant {
assert(this.x > 0);
assert(this.y > 0);
}
}

class C : A {
override void set (int x, int y)
in {
// Cannot work with override
assert(x > -4);
assert(y > -2);
}
body {
this.x = x;
this.y = y;
}
 override int mul()
out (ret) {
assert(ret > -4);
}
body {
return x * y;
}

// This cannot work. Less restrictive than parent
invariant {
assert(this.x > -4);
assert(this.y > -2);
}
}


void main()
{
A a = new A;
B b = new B;
C c = new C;
a.set(4,2);
writeln("Ans: ", a.mul());
// -1 is invalid
//a.set(-1, 0); core.exception.AssertError@sample.d(10): Assertion failure

b.set(5,3); // Fine with B. B is different type.
writeln("Ans: ", b.mul());
}
=


As you can see, D has type safety by contracts and does non-intuitive
checks.
Question is "Does PHP need this kind of type safety?"

I totally agree strict type safety is good for writing correct programs,
BTW.
D has type safety feature since it has strong type. If PHP is going to be
strongly typed language as scalar type hint RFC, and might be stronger
type than now. We may consider stricter types later. It's not just time for
it. IMHO.
PHP may be extended to check contracts like D when
declare('strict_types'=1).

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Robert,

D and PHP differs a lot with respect to types. D is very strongly typed
while PHP is very weakly typed.
Therefore, we need a little different approach.

On Sat, Feb 14, 2015 at 8:06 PM, Robert Stoll  wrote:

> The theory is actually quite simple. Roughly it says that if you use a
> type hint of a certain class then you can rely on all pre/post-conditions
> of this class even if a sub-class is passed. Hence the sub-class cannot
> have more restrict conditions. Consider the following (no longer sure which
> syntax is the one you intend to use, so I just use pre and post):
>
> class A{
>   function foo($x){
>  pre($x > 100);
>   }
> }
>
> class B extends A{
>   function foo($x){
> pre($x > 50); // less restrictive, that's fine
>   }
> }
>
> class C{
>   function foo($x){
> pre($x > 150); //more restrictive that's not allowed
>   }
> }
>
> function foo(A $a){
>   $a->foo(101); // that is ok as long as LSP is not violated
> }
>
> foo(new A()); //that's fine
> foo(new B()); //fine as well
> foo(new C()); //nope, C violates LSP and thus will result in an error
>

Correct. D does not allow to change parents contract. D does fancy check
for "overridden" methods
so that child cannot change parent behavior. I agree this is correct for
type safety.

Since D is strongly typed, D has "overloading" and D user can get around
with the previous restriction
easily.
e.g. foo(x, y) in class B will ignore A::foo contract at all. Same applies
to type difference, since
this is what "overloading" is.

PHP is weakly typed. There is no point follow D principle for "overridden"
methods because PHP type
is weak and PHP does not have "overloading".

I think this answers to your question.

Regards,

P.S. Are we really going to consider strict type safety for PHP??

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

All: I'll be continuing work on the RFC tomorrow, it is still in draft.

Yasuo: I'll read through your notes tomorrow, thanks for detailed input.

Cheers
Joe

On Sat, Feb 14, 2015 at 9:17 AM, Yasuo Ohgaki  wrote:

> Hi Francois,
>
> Now I understand what you are discussing. Since we may have stricter
> typing, we probably better
> to consider type safety theory even if PHP is weakly typed.
>
> What I'm going to write is not type theory, though.
>
> On Sat, Feb 14, 2015 at 3:16 PM, François Laupretre 
> wrote:
> >
> > The theory (from Eiffel guru) states that, to respect this fucking LSP
> rule, the pre-conditions to check when entering a method must be less
> strict than when entering its parent method. Don’t ask why, I don’t
> understand the reason very well. But that’s his rule, and everyone seems to
> respect it.
> >
> >
> >
> > In your RFC, you say that, when we enter a method, we must check its
> pre-conditions, as well as the ones of every parents. As you can only add
> conditions, compared to what you would do for the parent, the checks can
> only be stricter (more conditions).
> >
>
> Pre/Postconditions should be checked only when parent method is called.
> That's what Eiffel does.
> Eiffel does not allow method overriding. Therefore, pre/postconditions of
> methods (not invariants.
> Invariants inherited implicitly(automatically) both Eiffel and D are
> evaluated except certain
> methods) cannot be evaluated automatically unless parent method is called.
>
> public function foo() {
> parent::foo(); // pre/post conditions are evaluated upon call
> }
>
> Since children's method may have whole different way of handing
> parameters,
> including swapping parameter order, adding/removing parameters, etc.
> Parameters cannot be checked automatically unless we have some kind of
> binding system that bind child parameter to parent parameter. Even if we
> have
> it, parameter for parents may be generated in function body. It cannot be
> perfect.
>
> Therefore, overridden method's parent precondition evaluation cannot be
> done
> until child calls it explicitly.  Postcondition is the same. Child object
> may
> return whatever return value it returns, there is no point checking parent
> method's postcondition automatically.
>
> Invariant are also pre/postcondition, but it differs.
>
> > The logic described in the D documentation is : if a method defines
> pre-conditions, check them and stop (don’t check parent’s pre-conditions).
> If the method does not define pre-conditions, go down one level and check
> if parent method defines some. As soon as a method defining pre-conditions
> is found, these are checked and control is returned without going further.
> This way, it is still the developer’s responsibility to loosen conditions
> in derived classes but it is possible. If you check every parent’s
> pre-conditions, it is just *not* possible.
> >
>
> Basic rule is we shouldn't be able to modify parent contracts(invariant,
> methods pre/postconditions).
> If we can change it, it's the same as changing type.  Your discussion
> applies to invariant and this
> is what you write, I suppose.
>
>
> Child only can strengthen contract(invariant)  e.g.
>
> age >= 0 (Human) The base class. Followings are children.
> age >= 18 (Adult) 18 or over is greater than 0. OK
> age <18 (Child) 0 to 18 are greater than 0. OK
> age < 0 (Alien) This cannot happen as Human subtype. It violates Human
> type
>
> Type safety is protected by invariant like this.
>
>
> >
> > I am not sure I am clear.
> >
> >
> >
> > I chose not to follow exactly this logic as I think we can do it more
> ‘PHP way’ (something like the way constructors and destructors explicitly
> call their parent methods). My logic is : if the method we are entering has
> no pre-conditions, we don’t check anything (don’t search a parent method).
> If it defines some, we execute them. I introduce a ‘special’ condition :
> the ‘@parent’ pseudo-condition means ‘go down checking my parent’s
> conditions’. This way, similar to ‘parent::__construct()’ logic allows the
> developer to decide if he wants to check parent’s conditions or not.
> >
>
> We should only evaluate method's contract(pre/postcondition) when it is
> called.
> We should always evaluate class contract(invariant) including parents
> when it is applicable. (exceptions are __construct/_destruct/etc)
>
> >
> >
> > Example :
> >
> >
> >
> > /**
> >
> > * @requires ($a < $b)
> >
> > * @requires @parent   <- Go checking parent’s pre-conditions
> >
> > * @requires …
> >
> >
> >
> > For better consistence, I chose to implement the same for
> post-conditions and invariants, but I am not sure I will keep
> >
> > the same logic.
> >
> >
> >
> > The only thing that remains not clear for me is the role of conditions
> defined in interfaces, as the D documentation says that they can be defined
> but it does not explain when they are checked. I assume this is considered
> as a parent but the order matters in pre-conditions as 

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Francois,

Now I understand what you are discussing. Since we may have stricter
typing, we probably better
to consider type safety theory even if PHP is weakly typed.

What I'm going to write is not type theory, though.

On Sat, Feb 14, 2015 at 3:16 PM, François Laupretre 
wrote:
>
> The theory (from Eiffel guru) states that, to respect this fucking LSP
rule, the pre-conditions to check when entering a method must be less
strict than when entering its parent method. Don’t ask why, I don’t
understand the reason very well. But that’s his rule, and everyone seems to
respect it.
>
>
>
> In your RFC, you say that, when we enter a method, we must check its
pre-conditions, as well as the ones of every parents. As you can only add
conditions, compared to what you would do for the parent, the checks can
only be stricter (more conditions).
>

Pre/Postconditions should be checked only when parent method is called.
That's what Eiffel does.
Eiffel does not allow method overriding. Therefore, pre/postconditions of
methods (not invariants.
Invariants inherited implicitly(automatically) both Eiffel and D are
evaluated except certain
methods) cannot be evaluated automatically unless parent method is called.

public function foo() {
parent::foo(); // pre/post conditions are evaluated upon call
}

Since children's method may have whole different way of handing parameters,
including swapping parameter order, adding/removing parameters, etc.
Parameters cannot be checked automatically unless we have some kind of
binding system that bind child parameter to parent parameter. Even if we
have
it, parameter for parents may be generated in function body. It cannot be
perfect.

Therefore, overridden method's parent precondition evaluation cannot be done
until child calls it explicitly.  Postcondition is the same. Child object
may
return whatever return value it returns, there is no point checking parent
method's postcondition automatically.

Invariant are also pre/postcondition, but it differs.

> The logic described in the D documentation is : if a method defines
pre-conditions, check them and stop (don’t check parent’s pre-conditions).
If the method does not define pre-conditions, go down one level and check
if parent method defines some. As soon as a method defining pre-conditions
is found, these are checked and control is returned without going further.
This way, it is still the developer’s responsibility to loosen conditions
in derived classes but it is possible. If you check every parent’s
pre-conditions, it is just *not* possible.
>

Basic rule is we shouldn't be able to modify parent contracts(invariant,
methods pre/postconditions).
If we can change it, it's the same as changing type.  Your discussion
applies to invariant and this
is what you write, I suppose.


Child only can strengthen contract(invariant)  e.g.

age >= 0 (Human) The base class. Followings are children.
age >= 18 (Adult) 18 or over is greater than 0. OK
age <18 (Child) 0 to 18 are greater than 0. OK
age < 0 (Alien) This cannot happen as Human subtype. It violates Human type

Type safety is protected by invariant like this.


>
> I am not sure I am clear.
>
>
>
> I chose not to follow exactly this logic as I think we can do it more
‘PHP way’ (something like the way constructors and destructors explicitly
call their parent methods). My logic is : if the method we are entering has
no pre-conditions, we don’t check anything (don’t search a parent method).
If it defines some, we execute them. I introduce a ‘special’ condition :
the ‘@parent’ pseudo-condition means ‘go down checking my parent’s
conditions’. This way, similar to ‘parent::__construct()’ logic allows the
developer to decide if he wants to check parent’s conditions or not.
>

We should only evaluate method's contract(pre/postcondition) when it is
called.
We should always evaluate class contract(invariant) including parents
when it is applicable. (exceptions are __construct/_destruct/etc)

>
>
> Example :
>
>
>
> /**
>
> * @requires ($a < $b)
>
> * @requires @parent   <- Go checking parent’s pre-conditions
>
> * @requires …
>
>
>
> For better consistence, I chose to implement the same for post-conditions
and invariants, but I am not sure I will keep
>
> the same logic.
>
>
>
> The only thing that remains not clear for me is the role of conditions
defined in interfaces, as the D documentation says that they can be defined
but it does not explain when they are checked. I assume this is considered
as a parent but the order matters in pre-conditions as we only execute the
first conditions we find. I think I’ll assume that ‘@parent’ means ‘check
the conditions defined in the parent method and the method of the interface
that defines it’. Unfortunately, interfaces have parents too and can define
methods with same name. So, it’s the same sort of problems as multiple
inheritance. I will need to make a choice here. The simplest one would be
‘no support for DbC in interfaces’.

The same rule for class appl

RE: [PHP-DEV] Design by Contract

[François Laupretre]

I will try to explain but that’s not so clear for me too.

 

The theory (from Eiffel guru) states that, to respect this fucking LSP rule, 
the pre-conditions to check when entering a method must be less strict than 
when entering its parent method. Don’t ask why, I don’t understand the reason 
very well. But that’s his rule, and everyone seems to respect it.

 

In your RFC, you say that, when we enter a method, we must check its 
pre-conditions, as well as the ones of every parents. As you can only add 
conditions, compared to what you would do for the parent, the checks can only 
be stricter (more conditions).

 

The logic described in the D documentation is : if a method defines 
pre-conditions, check them and stop (don’t check parent’s pre-conditions). If 
the method does not define pre-conditions, go down one level and check if 
parent method defines some. As soon as a method defining pre-conditions is 
found, these are checked and control is returned without going further. This 
way, it is still the developer’s responsibility to loosen conditions in derived 
classes but it is possible. If you check every parent’s pre-conditions, it is 
just *not* possible.

 

I am not sure I am clear.

 

I chose not to follow exactly this logic as I think we can do it more ‘PHP way’ 
(something like the way constructors and destructors explicitly call their 
parent methods). My logic is : if the method we are entering has no 
pre-conditions, we don’t check anything (don’t search a parent method). If it 
defines some, we execute them. I introduce a ‘special’ condition : the 
‘@parent’ pseudo-condition means ‘go down checking my parent’s conditions’. 
This way, similar to ‘parent::__construct()’ logic allows the developer to 
decide if he wants to check parent’s conditions or not.

 

Example :

 

/**

* @requires ($a < $b)

* @requires @parent   <- Go checking parent’s pre-conditions

* @requires …

 

For better consistence, I chose to implement the same for post-conditions and 
invariants, but I am not sure I will keep

the same logic.

 

The only thing that remains not clear for me is the role of conditions defined 
in interfaces, as the D documentation says that they can be defined but it does 
not explain when they are checked. I assume this is considered as a parent but 
the order matters in pre-conditions as we only execute the first conditions we 
find. I think I’ll assume that ‘@parent’ means ‘check the conditions defined in 
the parent method and the method of the interface that defines it’. 
Unfortunately, interfaces have parents too and can define methods with same 
name. So, it’s the same sort of problems as multiple inheritance. I will need 
to make a choice here. The simplest one would be ‘no support for DbC in 
interfaces’.

 

 

De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Envoyé : samedi 14 février 2015 05:16
À : francois
Cc : Dmitry Stogov; Joe Watkins; Stanislav Malyshev; PHP Internals
Objet : Re: [PHP-DEV] Design by Contract

 

Hi Francois,

 

On Sat, Feb 14, 2015 at 12:53 PM, Yasuo Ohgaki  wrote:

On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre  wrote:

> For method calls, overridden method should not evaluate parents contract on 
> entry.
> It should be evaluated when parent method is called.

I already told you : the logic you are using for pre-conditions is NOT 
compatible with Eiffel and D logic, although this is what you're supposed to 
mimic. It is actually the opposite. Is it a wanted behavior ? because you 
should be aware that it does not respect the LS principle.


Did you mean "Least Concern Principle" here?


I'm lost here. Eiffel does not even allow method overriding. Therefore, child 
class's method contract 

will never evaluated unless it is explicitly called. Semantics is basically the 
same as what I wrote. 

(Eiffel requires to drop parent method by "redefine" or rename parent method by 
"rename" when 

the same method name is needed)

 

I agree that Eiffel's approach is stricter with respect to least concern 
principle.

It's just not suitable for PHP, is it?

 

Similar argument can be done for D's invariant. D dropped invariant from class 
in favor of

immutables. Immutable is better for least concern, but we don't have immutables 
now.

Even if we have it, people would like to manage object state. We may have both.

 

Anyway, could you explain what kind of issues we may have?

 

Regards,




--
Yasuo Ohgaki 
yohg...@ohgaki.net

RE: [PHP-DEV] Design by Contract

[François Laupretre]

> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
>Open discussion is needed, of course.
>What I meant is discussion for writing up draft RFC is close to finish.

That's fine.

> > For method calls, overridden method should not evaluate parents contract on 
> > entry.
> > It should be evaluated when parent method is called.
>
> I already told you : the logic you are using for pre-conditions is NOT 
> compatible with Eiffel and D logic, although this is what 
>you're supposed to mimic. It is actually the opposite. Is it a wanted behavior 
>? because you should be aware that it does not 
>respect the LS principle.
>
> I'll check how your RFC is handling this later.

My RFC does not mimic the D logic but that's a choice. I just want to ensure it 
is the same for you. And it is not clearly explained in your RFC.

> > - Consider introduction of static require() as class invariant for static 
> > methods
> > I probably don't understand the idea correctly. Could you give some 
> > explanations?
>
> He's probably talking about a new set of conditions that couldn't use 
> '$this'. Unlike 'dynamic' invariants, these can also be 
> checked before and after static methods.
> OK. So it's for invariant.

Yes, it's a way to check static properties more often.

> My RFC is not supposed to be implemented in the core. Derick is OK to help me 
> adding the feature to Xdebug. This way, it will be available for every PHP 
> versions supported by Xdebug.
>
> Actually, I keep the RFC to get people's opinion and to refine what I have in 
> mind after scalar type hints are voted upon but, technically, I don't need it 
> anymore.

>I see. Xdebug or other annotation would work.

Yes, using doc comments should allow to implement it without changing anything 
in the core. Another 'pluggable' annotation system could be a solution but 1. 
It cannot be available before a long time, and 2. It won't be available on PHP 
5.

>Did gmail something wrong? What kind of problem was it?
>I've removed text formatting, so this time it shouldn't have issues.

Well, prefixes are OK but your messages are in HTML. Replying to raw text would 
be much easier for us (I don't know how it can be done in gmail).

Regards,

François


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Design by Contract

[François Laupretre]

>De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
>Did you mean "Least Concern Principle" here?

No : http://en.wikipedia.org/wiki/Liskov_substitution_principle.

IMO, it is just a sort of best practice but OO people love it.

François


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Francois,

On Sat, Feb 14, 2015 at 12:53 PM, Yasuo Ohgaki  wrote:

> On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre 
> wrote:
>
>> > For method calls, overridden method should not evaluate parents
>> contract on entry.
>> > It should be evaluated when parent method is called.
>>
>> I already told you : the logic you are using for pre-conditions is NOT
>> compatible with Eiffel and D logic, although this is what you're supposed
>> to mimic. It is actually the opposite. Is it a wanted behavior ? because
>> you should be aware that it does not respect the LS principle.
>
>
> Did you mean "Least Concern Principle" here?


I'm lost here. Eiffel does not even allow method overriding. Therefore,
child class's method contract
will never evaluated unless it is explicitly called. Semantics is basically
the same as what I wrote.
(Eiffel requires to drop parent method by "redefine" or rename parent
method by "rename" when
the same method name is needed)

I agree that Eiffel's approach is stricter with respect to least concern
principle.
It's just not suitable for PHP, is it?

Similar argument can be done for D's invariant. D dropped invariant from
class in favor of
immutables. Immutable is better for least concern, but we don't have
immutables now.
Even if we have it, people would like to manage object state. We may have
both.

Anyway, could you explain what kind of issues we may have?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Francois,

On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre 
wrote:

> > For method calls, overridden method should not evaluate parents contract
> on entry.
> > It should be evaluated when parent method is called.
>
> I already told you : the logic you are using for pre-conditions is NOT
> compatible with Eiffel and D logic, although this is what you're supposed
> to mimic. It is actually the opposite. Is it a wanted behavior ? because
> you should be aware that it does not respect the LS principle.


Did you mean "Least Concern Principle" here?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi all,

On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre 
wrote:
>
> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
> >
> > We have discussed most of issues for https://wiki.php.net/rfc/dbc2
>
> I am not sure anyone except hardly 5 people has the impression that the
subject was discussed, as the RFCs were not even officially announced on
the list. OK, you discussed with 2 or 3 people about building your RFC.
Now, the RFC is here, and the REAL OPEN discussion can start with a new
thread prefixed with '[RFC]'. You cannot open a vote before anyone had a
chance to give its opinion.

Open discussion is needed, of course.
What I meant is discussion for writing up draft RFC is close to finish.

>
> Actually, I was waiting for the end of the 'scalar type hinting' vote to
start the DbC discussion but we can start it now.
>

Yes, if we can confirm everyone think the draft is ready to be discussed.
According to RFC for voting. We must send mail titled "[RFC]" for
discussion.

> About all the missing stuff you include in your mail, is your RFC really
ready to start a discussion if there are still so many missing things ? I'm
afraid it is not.

Don't worry, we'll have discussion for vote. We had discussion for writing
RFC.

>
> > "These observations shed light on the true significance of inheritance:
not just a reuse,
> > subtyping and classification mechanism, but a way to ensure compatible
semantics by
> > other means. They also provide useful guidance as to how to use
inheritance properly."
>
> Do you seriously plan to include such bullshit in your RFC ?

I don't care. It's a statement from Eiffel folks. We don't have buy it.

>
> > For method calls, overridden method should not evaluate parents
contract on entry.
> > It should be evaluated when parent method is called.
>
> I already told you : the logic you are using for pre-conditions is NOT
compatible with Eiffel and D logic, although this is what you're supposed
to mimic. It is actually the opposite. Is it a wanted behavior ? because
you should be aware that it does not respect the LS principle.

I'll check how your RFC is handling this later.

>
> > - Consider introduction of static require() as class invariant for
static methods
> > I probably don't understand the idea correctly. Could you give some
explanations?
>
> He's probably talking about a new set of conditions that couldn't use
'$this'. Unlike 'dynamic' invariants, these can also be checked before and
after static methods.

OK. So it's for invariant.

>
> > Syntax is not my priority.
> > We are better to avoid new keyword whenever it's possible.
>
> Just my opinion : syntax IS important. I agree that new keywords should
be avoided but reusing 'require' and 'return' is too ambiguous. I say that
syntax is important because I'm sure that's the only point people will
complain about.

Right. That's the reason why syntax is not important to me.
I just would like to accept whatever syntax that does not have issues.

>
> > How to manage votes for 2 RFCs
>
> Your RFC is not even ready for discussion. Anyway, the vote will probably
be about your RFC only.

Yes, we need to finish draft for discussion.
Why? There are many who people like annotation approach.

>
> > ==Annotation DbC Implementation==
> > Dmitry, I guess it wouldn't be too hard for you to implement this RFC.
How about annotation
> > version? Can it be implemented with reasonable amount of efforts?
>
> My RFC is not supposed to be implemented in the core. Derick is OK to
help me adding the feature to Xdebug. This way, it will be available for
every PHP versions supported by Xdebug.
>
> Actually, I keep the RFC to get people's opinion and to refine what I
have in mind after scalar type hints are voted upon but, technically, I
don't need it anymore.

I see. Xdebug or other annotation would work.
I didn't have much time to read/verify your RFC. I'll read it again soon.

>
> > Native DbC support syntax:
> > class Child {
> > require($this->age < 18); // Invariant (Class state condition)
>
> If, after writing the RFC, you keep writing your conditions after the
first '{', are you sure your syntax is so intuitive ? ;)

Any syntax needs time to getting use to it :)

>
> And, please, prefix lines with '>' chars when you post a reply. Thanks.

Did gmail something wrong? What kind of problem was it?
I've removed text formatting, so this time it shouldn't have issues.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

RE: [PHP-DEV] Design by Contract

[François Laupretre]

Hi Yasuo,

> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
> We have discussed most of issues for https://wiki.php.net/rfc/dbc2

I am not sure anyone except hardly 5 people has the impression that the subject 
was discussed, as the RFCs were not even officially announced on the list. OK, 
you discussed with 2 or 3 people about building your RFC. Now, the RFC is here, 
and the REAL OPEN discussion can start with a new thread prefixed with '[RFC]'. 
You cannot open a vote before anyone had a chance to give its opinion.

Actually, I was waiting for the end of the 'scalar type hinting' vote to start 
the DbC discussion but we can start it now.

About all the missing stuff you include in your mail, is your RFC really ready 
to start a discussion if there are still so many missing things ? I'm afraid it 
is not.

> "These observations shed light on the true significance of inheritance: not 
> just a reuse, 
> subtyping and classification mechanism, but a way to ensure compatible 
> semantics by 
> other means. They also provide useful guidance as to how to use inheritance 
> properly."

Do you seriously plan to include such bullshit in your RFC ?

> For method calls, overridden method should not evaluate parents contract on 
> entry.
> It should be evaluated when parent method is called. 

I already told you : the logic you are using for pre-conditions is NOT 
compatible with Eiffel and D logic, although this is what you're supposed to 
mimic. It is actually the opposite. Is it a wanted behavior ? because you 
should be aware that it does not respect the LS principle.

> - Consider introduction of static require() as class invariant for static 
> methods
> I probably don't understand the idea correctly. Could you give some 
> explanations?

He's probably talking about a new set of conditions that couldn't use '$this'. 
Unlike 'dynamic' invariants, these can also be checked before and after static 
methods.

> Syntax is not my priority.
> We are better to avoid new keyword whenever it's possible.

Just my opinion : syntax IS important. I agree that new keywords should be 
avoided but reusing 'require' and 'return' is too ambiguous. I say that syntax 
is important because I'm sure that's the only point people will complain about.

> How to manage votes for 2 RFCs

Your RFC is not even ready for discussion. Anyway, the vote will probably be 
about your RFC only.

> ==Annotation DbC Implementation==
> Dmitry, I guess it wouldn't be too hard for you to implement this RFC. How 
> about annotation
> version? Can it be implemented with reasonable amount of efforts?

My RFC is not supposed to be implemented in the core. Derick is OK to help me 
adding the feature to Xdebug. This way, it will be available for every PHP 
versions supported by Xdebug.

Actually, I keep the RFC to get people's opinion and to refine what I have in 
mind after scalar type hints are voted upon but, technically, I don't need it 
anymore.

> Native DbC support syntax:
> class Child {
> require($this->age < 18); // Invariant (Class state condition)

If, after writing the RFC, you keep writing your conditions after the first 
'{', are you sure your syntax is so intuitive ? ;)

And, please, prefix lines with '>' chars when you post a reply. Thanks.

Cheers

François



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

On Sat, Feb 14, 2015 at 8:19 AM, Yasuo Ohgaki  wrote:

>  myMethod() {
>   require(MyMethod());
>  }
>

My hand is not used to new syntax yet. This should be.

myMethod()
  require(myMethid())
{
  /* */
}

==
Native DbC support syntax:
class Child {
require($this->age < 18); // Invariant (Class state condition)

public function someMethod($input)
require(somethingAbout($input)) // Precondition
return($ret, somethingReturn($ret)) // Postcondition
{
/* Great! We are certain that caller satisfy precondition, return
   appropriate return value and have proper class state! */
}
}

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi all,

We have discussed most of issues for https://wiki.php.net/rfc/dbc2

==Missing parts of the RFC for me==

 - Advantage over annotation:
  Written as code, executed as code. ("Written as document, available
as document" would be
  annotation advantage)

 - Advantage over assert() only solution:
  Part of DbC can be done by assert() only, but it reduces readability.
Post condition can be
  located anywhere in function. It makes difficult to distinguish if
assert() is contract or internal
  error. Invariant helps to reduce number of assert() a lot. In short,
contract and internal logic
  assertion is different assertion.
  DbC encourage proper class design. It's taken from Eiffel site.
https://www.eiffel.com/values/design-by-contract/introduction/
"These observations shed light on the true significance of
inheritance: not just a reuse,
 subtyping and classification mechanism, but a way to ensure
compatible semantics by
 other means. They also provide useful guidance as to how to use
inheritance properly."

  DbC encourages proper secure design. Since DbC removes all assertion
from production
  code, users must ensure app input/output validity when it accepts
input and write outputs.
 http://cwe.mitre.org/top25/#Mitigations

https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf
   DbC also encourages proper defense in depth, since users must think
"where is the
   best place for defense in depth?" with DbC.
   These helps users to adopt desirable secure and efficient
application architecture. This
   cannot be accomplished only by assert().

 - Recursion
 Since DbC evaluate contracts automatically, certain code may lead to
infinite recursion.
 Most obvious is calling itself. e.g.
 myMethod() {
  require(MyMethod());
 }
 We don't need protections for bad code.

 - Clearness:
  Interface/trait support. I suppose it is. Am I correct?
  Normal function support may not be obvious for people didn't involve
discussion.
  Global invariant (main function invariant). This is not supported.

 - Future scope:
  Internal module class/interface support. e.g. SessionHandlerInterface
  Someone may insist immutable over invariant. Immutable and invariant
is not the
  same for me. It may be better  to state "immutables" as stricter
constraint.

Joe, could you add some them? You do better job than me :) I don't mind
whichever
you pick. These are not mandatory.

==Ideas for open issues==

 - Contracts inheritance rules

Invariant should be implicit like D and Eiffel and evaluated always under
DbC mode.
For method calls, overridden method should not evaluate parents contract on
entry.
It should be evaluated when parent method is called.

D had restriction to call public methods from invaliant. Calling public
method from
invariant might be better to be restricted. It might be OK to allow user to
shoot
their own foot since user can do that with protected/private method anyway.

 - Consider introduction of static require() as class invariant for static
methods

I probably don't understand the idea correctly. Could you give some
explanations?

 - Need to discuss syntax

There were many ideas for possible syntaxes, I prefer current simple syntax.
Syntax is not my priority. I don't mind require{assert();},
return{assert();}, etc.
Since "error message" can be added and any expression is allowed, writing
contracts
as code may be better. We are better to avoid new keyword whenever it's
possible.

 - How to manage votes for 2 RFCs

Both RFCs are large enough. How about make vote only RFC
https://wiki.php.net/rfc/dbc_vote
 - Explain what is DbC.
 - Choose "Introduce Native DbC for PHP - Yes or No"
 - For people voted for Yes, "Annotation or Code" refer
   links to https://wiki.php.net/rfc/dbc, https://wiki.php.net/rfc/dbc2
  - Choose "Annotation or Code"


==Annotation DbC Implementation==
Dmitry, I guess it wouldn't be too hard for you to implement this RFC. How
about annotation
version? Can it be implemented with reasonable amount of efforts?



Thank you all those who are contributed discussion!
I hope you choose to have DbC support. DbC helps to achieve "strict/precise
development"
and "maximum performance in production" at the same time.

Regards,

P.S. It takes time to get used to new syntax. We may be better try to
expose new syntax
as much as possible. i.e. Put new syntax in mails whenever possible.

Native DbC support syntax:
class Child {
require($this->age < 18); // Invariant (Class state condition)

public function someMethod($input)
require(somethingAbout($input)) // Precondition
return($ret, somethingReturn($ret)) // Postcondition
{
/* Great! We are certain that caller satisfy precondition, return
   appropriate return value and have proper class state! */
}
}

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

Hi,

On Wed, Feb 11, 2015 at 10:05 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > That one actually looks better to me, but: I'm not sure how
> annotation
> > syntax is supposed to support expressions or closures,
> >
> >
> > keep AST.
>
> So we'd have a zval type that is the raw AST? Would it also be available
> to user functions or internal functions/classes? It's an intriguing
> concept but I'm not sure we appreciate all the consequences of it -
> adding new type is a rather big change as everything should support it.
> Or did you mean something else?
>

This is just an initial idea, and some research is required.
I don't propose to add new ZVAL type. AST may be just stored internally and
accesses through extended Reflection API.
This API may provide some classes to represent AST nodes.


> > Is it some special form of annotation for this
> > purpose only (meh)?
> >
> >
> > yes. some special attributes. requires/ensures/invariant
>
> Ah, so <> annotation would work different than any other type
> of annotation? Then I don't see any use for it to use annotation syntax
> (whatever it would be) - same syntax should mean same or at least
> similar function. Maybe I am still missing what you meant.
>

I don't understand you as well. It should be clear, that annotation should
allow declaration of any attributes, and some of them may be used for
different purposes. some for DbC.


>
> > Oh, and <<>> syntax is *ugly* ;)
> >
> >
> > It's from HHVM. I don't like it as well, please, propose the better one.
>
> Pretty much every other one is better:
> Java and the followers, Python: @foo
> C#: [foo]
>

[foo] is already a legal syntax in PHP - array with constant foo.

Thanks. Dmitry.


>
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] Design by Contract

[Stanislav Malyshev]

Hi!

> That one actually looks better to me, but: I'm not sure how annotation
> syntax is supposed to support expressions or closures,
> 
> 
> keep AST.

So we'd have a zval type that is the raw AST? Would it also be available
to user functions or internal functions/classes? It's an intriguing
concept but I'm not sure we appreciate all the consequences of it -
adding new type is a rather big change as everything should support it.
Or did you mean something else?

> Is it some special form of annotation for this
> purpose only (meh)?
> 
> 
> yes. some special attributes. requires/ensures/invariant

Ah, so <> annotation would work different than any other type
of annotation? Then I don't see any use for it to use annotation syntax
(whatever it would be) - same syntax should mean same or at least
similar function. Maybe I am still missing what you meant.

> Oh, and <<>> syntax is *ugly* ;)
> 
> 
> It's from HHVM. I don't like it as well, please, propose the better one.

Pretty much every other one is better:
Java and the followers, Python: @foo
C#: [foo]

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Lester Caine]

On 11/02/15 14:14, François Laupretre wrote:
>> All of the current demands ... and I think they are demands! ... stamp
>> > on past history and load even more work on everybody to have to support
>> > all these new features. Even if dbc is wrapped in comment blocks to hide
>> > it it's potential presence in third party parts of a project means that
>> > all tools have to be modified and my use of phpdoc is further eroded.
> The proposal to embed DbC conditions in phpdoc is just defining new '@' 
> keywords. That's the implicit way such a basic annotation system works : 
> tools ignore the lines they don't understand. I ran phpDocumentor on 
> DbC-commented script files,  and it still produces the same documentation. 
> It's supposed to be the same with everyone extending phpdoc syntax.
> 
> So, I don't understand why you should modify any of your tools.

While phpDocumentor can ignore elements it does not understand, that
information would be useful to maintain, so some modification of it's
parsing would be appropriate. But I was referring more to the other
proposals for adding essentially the same information, and how that
might be hidden in non-docblock comment packets.

But currently some tools are lagging behind even current changes in PHP
and phpDocumentor does not get everything right already. I can't get a
clean set of documents currently with either the original version or the
Mk2 version of phpDocumentor on code that has produced clean documents
in the past. Just another area that needs time spending to work out what
now need updating which does not affect the working code.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Design by Contract

[François Laupretre]

Hi Lester,

> All of the current demands ... and I think they are demands! ... stamp
> on past history and load even more work on everybody to have to support
> all these new features. Even if dbc is wrapped in comment blocks to hide
> it it's potential presence in third party parts of a project means that
> all tools have to be modified and my use of phpdoc is further eroded.

The proposal to embed DbC conditions in phpdoc is just defining new '@' 
keywords. That's the implicit way such a basic annotation system works : tools 
ignore the lines they don't understand. I ran phpDocumentor on DbC-commented 
script files,  and it still produces the same documentation. It's supposed to 
be the same with everyone extending phpdoc syntax.

So, I don't understand why you should modify any of your tools.

Cheers

François


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Design by Contract

[François Laupretre]

> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
> Ohgaki
>
> Both D and Eiffel evaluates all contracts defined in parents/interfaces.

That's not what I understand about pre-condition inheritance in D (check 
http://ddili.org/ders/d.en/invariant.html#ix_invariant.contract%20inheritance) :

> Upon entering a function, the in blocks are executed automatically from the 
> topmost type to the bottom-most type
> in the hierarchy . If **any in block** succeeds without any assert failure, 
> then the preconditions are considered to be
> fulfilled.

And later :

> Derived types can define in blocks for overridden member functions. 
> Preconditions of a derived type should not be
> stricter than the preconditions of its bases. (Note that not defining an in 
> block means "no precondition at all", which
> may not be the intent of the programmer.)

The D documentation is not clear about interface inheritance, especially 
regarding pre-conditions.

I am OK with the fact that post-conditions and invariants must verify the 
constraints defined in their ancestors (parent classes and interfaces), but, 
for pre-conditions, I would prefer an optional explicit reference to the 
parent's constraints.

Cheers

François


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Design by Contract

[François Laupretre]

> De : Dmitry Stogov [mailto:dmi...@zend.com]
> 
> I think we should just repeat the related D semantic.
> It must be defined in contracts inheritance rules.
> 
> What if we have contracts for prototype method in parent class and
> interface?
> Should we still validate contracts of parent and interface if we add our
> owns?
> etc.

I would prefer contract inheritance to follow a logic more similar to what we 
use for PHP constructors/destructors (parent method is executed only if 
explicitely called). 'require(@parent)', for example, would mean 'check parent 
pre-conditions !'. The same for every constraint type.

This is not exactly the D way but is is more consistent with the PHP way. And 
there's no real reason to follow D there.

Not sure we should authorize constraints in interfaces, at least for a first 
version.

Cheers

François


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[S.A.N]

2015-02-11 13:25 GMT+02:00 Dmitry Stogov :
>
> yes. some special attributes. requires/ensures/invariant
>
>
>> Oh, and <<>> syntax is *ugly* ;)
>>
>
> It's from HHVM. I don't like it as well, please, propose the better one.
>

I like syntax, like a switch:

function add(int $a, int $b) : int
case $a > 0:
case $b > 0:
return($ret, $ret > 0, "something wrong")
{
return $a + $b;
}

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

On Wed, Feb 11, 2015 at 10:58 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > 1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
> >
> > /**
> >  * @requires ($a >= 0)
> >  */
> > function foo($a) {
> > }
>
> We've spent several years rejecting annotations because no information
> can be in comments, not even a little bit, not even a tiny. Now we'd
> have full-blown running code in comments? How would this code be
> debugged/profiled/interpreted by tools? Writing PHP parser is not easy
> right now, but this would turn it into nightmare (what if you have a
> comment inside @requires? etc.)
>

I don't see how this can be implemented in PHP core as well.
This approach is for external tools.


>
> > 2) contracts as part of the language https://wiki.php.net/rfc/dbc2
> >
> > function foo($a)
> > require($a >= 0)
> > {
> > }
>
> This is a step better but still we have the similar issues with
> readability, to which reuse of 'require' is added.
>
> > 3) contracts in annotations
> >
> > <= 0)>>
> > function foo($a) {
> > }
>
> That one actually looks better to me, but: I'm not sure how annotation
> syntax is supposed to support expressions or closures,


keep AST.


> yet more - how it
> is supposed to share the scope with the function. I.e., if you define
> annotation class/method/function/data structure/whatever it is, what it
> is supposed to receive?


We may have AST transformation pass that would convert these annotations
into assert() and insert them into AST of the function.


> Is it some special form of annotation for this
> purpose only (meh)?
>

yes. some special attributes. requires/ensures/invariant


> Oh, and <<>> syntax is *ugly* ;)
>

It's from HHVM. I don't like it as well, please, propose the better one.

Thanks. Dmitry.


>
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] Design by Contract

[Lester Caine]

On 11/02/15 07:58, Stanislav Malyshev wrote:
> We've spent several years rejecting annotations because no information
> can be in comments, not even a little bit, not even a tiny.

I find that a strange comment, since I've been using annotation in PHP
from day one. The phpdoc material helped me get started all those years
ago since every third party library had it as part of their coding style
from PHP4 days.

All of the current demands ... and I think they are demands! ... stamp
on past history and load even more work on everybody to have to support
all these new features. Even if dbc is wrapped in comment blocks to hide
it it's potential presence in third party parts of a project means that
all tools have to be modified and my use of phpdoc is further eroded.

I see all these comments about 'D' and 'Effiel' and my ONLY thought is
... Then bloody use that! ... Even the people demanding strict typing!

DbC does not have to modify the core code to be usable by those wanting
it. In the same way that phpdoc has never needed that. BUT a means of
expanding the /* */ wrapper to include extra types over the /** tag may
be appropriate, then people can use their own preferred annotation
system, and other tools can simply 'switch off' where appropriate. While
I don't feel 'compiling' is the right way forward for PHP projects, the
'min' processing of files as applied to just about every other scripting
element does make sense as a half way house to opcode caching.

( and some help with actually fixing php7 in code would be appreciated! )

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Tony Marston]

"Stanislav Malyshev"  wrote in message news:54dafd32.3000...@gmail.com...


Hi!


Please steer clear of using the assert API, and in so doing avoid BC
concerns with the current assert API.


The operator can be called something other than "assert", I'm sure the
thesaurus has a lot of possibilities.


How about "pre_assert" and "post_assert"? As Dbc is supposed to be about 
defining preconditions and postconditions the use of the word "pre" and 
"post" would seem appropriate.


--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> http://dlang.org/deprecate.html#invariant as an alias for immutable

It's not an alias, the most recent compiler emits an error if you try to
use invariant contracts, and immutable isn't a kind of contract.

immutable is a property modifier:

immutable: http://dpaste.dzfl.pl/7e724b599640
invariant (won't compile using latest release):
http://dpaste.dzfl.pl/102c5c5adef5

> Isn't invariant good enough?

Good enough for us, yeah.

Cheers
Joe

On Wed, Feb 11, 2015 at 8:18 AM, Yasuo Ohgaki  wrote:

> Hi Joe,
>
> On Wed, Feb 11, 2015 at 5:02 PM, Yasuo Ohgaki  wrote:
>
>> On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins 
>> wrote:
>>
>>> So it turns out that invariant is already deprecated in D, they have
>>> dropped it in favour of immutable properties.
>>>
>>> I guess I'll have to install an old version, or try to extract
>>> everything we need from their obviously outdated documentation ...
>>>
>>
>> That's too bad.
>> Eiffel uses invariant.
>>
>> https://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions
>>
>
> http://dlang.org/deprecate.html#invariant as an alias for immutable
>
> I  think D folks would like to be more strict. Object is great, but state
> management can be complex.
> I like immutable also since it prevents modification by mistake. I'm not
> sure if we should go for it
> without having invariant. Even if we have invariant, we may have immutable
> object/scalar in the future.
> Both are good.
>
> Isn't invariant good enough? I don't think Eiffel will drop invariant
> support in favor of immutables.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Joe,

On Wed, Feb 11, 2015 at 5:12 PM, Joe Watkins  wrote:

> > Just a thought - what about something like __pre/__post? We own __*, so
> no BC problems.
>
> I'm not married to the words being used, at all.
>
> I think this is a good idea, we would need __pre, __post , and
> __invariant, or some combination of three.
>
> Any objection to using __ prefixed names, and any other suggestion for
> them, or just use the above ?
>

It's very close to my original idea, but I like current definition like
syntax.
No objection from me...

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Joe,

On Wed, Feb 11, 2015 at 5:02 PM, Yasuo Ohgaki  wrote:

> On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins 
> wrote:
>
>> So it turns out that invariant is already deprecated in D, they have
>> dropped it in favour of immutable properties.
>>
>> I guess I'll have to install an old version, or try to extract everything
>> we need from their obviously outdated documentation ...
>>
>
> That's too bad.
> Eiffel uses invariant.
>
> https://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions
>

http://dlang.org/deprecate.html#invariant as an alias for immutable

I  think D folks would like to be more strict. Object is great, but state
management can be complex.
I like immutable also since it prevents modification by mistake. I'm not
sure if we should go for it
without having invariant. Even if we have invariant, we may have immutable
object/scalar in the future.
Both are good.

Isn't invariant good enough? I don't think Eiffel will drop invariant
support in favor of immutables.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> OTOH, don't our new parsing improvements allow us to handle syntax like
this without introducing a keyword that would be forbidden as
class/function name

Not that I am aware of, the AST stuff didn't touch the parser like that, it
has the same limitations it had before AFAIK.

Cheers
Joe

On Wed, Feb 11, 2015 at 8:12 AM, Joe Watkins  wrote:

> > Just a thought - what about something like __pre/__post? We own __*, so
> no BC problems.
>
> I'm not married to the words being used, at all.
>
> I think this is a good idea, we would need __pre, __post , and
> __invariant, or some combination of three.
>
> Any objection to using __ prefixed names, and any other suggestion for
> them, or just use the above ?
>
> Cheers
> Joe
>
>
> On Wed, Feb 11, 2015 at 8:09 AM, Stanislav Malyshev 
> wrote:
>
>> Hi!
>>
>> >> function foo($a)
>> >> require($a >= 0)
>> >> {
>> >> }
>> >
>> > This is a step better but still we have the similar issues with
>> > readability, to which reuse of 'require' is added.
>>
>> Just a thought - what about something like __pre/__post? We own __*, so
>> no BC problems.
>> OTOH, don't our new parsing improvements allow us to handle syntax like
>> this without introducing a keyword that would be forbidden as
>> class/function name? The context is pretty unambiguous here.
>> --
>> Stas Malyshev
>> smalys...@gmail.com
>>
>
>

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.

I'm not married to the words being used, at all.

I think this is a good idea, we would need __pre, __post , and __invariant,
or some combination of three.

Any objection to using __ prefixed names, and any other suggestion for
them, or just use the above ?

Cheers
Joe


On Wed, Feb 11, 2015 at 8:09 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> >> function foo($a)
> >> require($a >= 0)
> >> {
> >> }
> >
> > This is a step better but still we have the similar issues with
> > readability, to which reuse of 'require' is added.
>
> Just a thought - what about something like __pre/__post? We own __*, so
> no BC problems.
> OTOH, don't our new parsing improvements allow us to handle syntax like
> this without introducing a keyword that would be forbidden as
> class/function name? The context is pretty unambiguous here.
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] Design by Contract

[Stanislav Malyshev]

Hi!

>> function foo($a)
>> require($a >= 0)
>> {
>> }
> 
> This is a step better but still we have the similar issues with
> readability, to which reuse of 'require' is added.

Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
OTOH, don't our new parsing improvements allow us to handle syntax like
this without introducing a keyword that would be forbidden as
class/function name? The context is pretty unambiguous here.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Joe,

On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins  wrote:

> So it turns out that invariant is already deprecated in D, they have
> dropped it in favour of immutable properties.
>
> I guess I'll have to install an old version, or try to extract everything
> we need from their obviously outdated documentation ...
>

That's too bad.
Eiffel uses invariant.
https://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Stanislav Malyshev]

Hi!

> 1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
> 
> /**
>  * @requires ($a >= 0)
>  */
> function foo($a) {
> }

We've spent several years rejecting annotations because no information
can be in comments, not even a little bit, not even a tiny. Now we'd
have full-blown running code in comments? How would this code be
debugged/profiled/interpreted by tools? Writing PHP parser is not easy
right now, but this would turn it into nightmare (what if you have a
comment inside @requires? etc.)

> 2) contracts as part of the language https://wiki.php.net/rfc/dbc2
> 
> function foo($a)
> require($a >= 0)
> {
> }

This is a step better but still we have the similar issues with
readability, to which reuse of 'require' is added.

> 3) contracts in annotations
> 
> <= 0)>>
> function foo($a) {
> }

That one actually looks better to me, but: I'm not sure how annotation
syntax is supposed to support expressions or closures, yet more - how it
is supposed to share the scope with the function. I.e., if you define
annotation class/method/function/data structure/whatever it is, what it
is supposed to receive? Is it some special form of annotation for this
purpose only (meh)?
Oh, and <<>> syntax is *ugly* ;)

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

So it turns out that invariant is already deprecated in D, they have
dropped it in favour of immutable properties.

I guess I'll have to install an old version, or try to extract everything
we need from their obviously outdated documentation ...

Grrr ...

Cheers
Joe

On Wed, Feb 11, 2015 at 7:50 AM, Yasuo Ohgaki  wrote:

> Hi Dmitry,
>
> On Wed, Feb 11, 2015 at 4:26 PM, Dmitry Stogov  wrote:
>
>> I think we should just repeat the related D semantic.
>> It must be defined in contracts inheritance rules.
>>
>> What if we have contracts for prototype method in parent class and
>> interface?
>> Should we still validate contracts of parent and interface if we add our
>> owns?
>> etc.
>
>
> Both D and Eiffel evaluates all contracts defined in parents/interfaces.
>
> Both D and Eiffel has method like invariant definition. They don't inherit
> explicitly, but inherit implicitly always. That's why I sent strange mail.
> I read code
> and misunderstood by mistake. I don't code with D much, but I really like
> the
> feature ;)
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry,

On Wed, Feb 11, 2015 at 4:26 PM, Dmitry Stogov  wrote:

> I think we should just repeat the related D semantic.
> It must be defined in contracts inheritance rules.
>
> What if we have contracts for prototype method in parent class and
> interface?
> Should we still validate contracts of parent and interface if we add our
> owns?
> etc.


Both D and Eiffel evaluates all contracts defined in parents/interfaces.

Both D and Eiffel has method like invariant definition. They don't inherit
explicitly, but inherit implicitly always. That's why I sent strange mail.
I read code
and misunderstood by mistake. I don't code with D much, but I really like
the
feature ;)

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> I think we should just repeat the related D semantic.

I'm not sure it all fits, some decisions were likely taken because of D's
object model.

I'm going to continue research today and will be updating the RFC, I'll aim
for as close to D as possible then.

Cheers
Joe

On Wed, Feb 11, 2015 at 7:26 AM, Dmitry Stogov  wrote:

> I think we should just repeat the related D semantic.
> It must be defined in contracts inheritance rules.
>
> What if we have contracts for prototype method in parent class and
> interface?
> Should we still validate contracts of parent and interface if we add our
> owns?
> etc.
>
> Thanks. Dmitry.
>
> On Wed, Feb 11, 2015 at 10:08 AM, Joe Watkins 
> wrote:
>
>> D has them:
>>
>> http://dlang.org/interface.html#interface-contracts
>>
>> Maybe we could allow pre/post contracts but invariants don't make sense
>> on interfaces.
>>
>> The question is, do we want to make them always available when possible,
>> or do we want to make them available where it seems most useful and or
>> least complex ?
>>
>> I prefer the latter, everyone else ?
>>
>> Cheers
>> Joe
>>
>> On Wed, Feb 11, 2015 at 7:02 AM, Dmitry Stogov  wrote:
>>
>>> I think we can't support contracts on interfaces and abstract methods.
>>> How D works?
>>>
>>> Thanks. Dmitry.
>>>
>>> On Wed, Feb 11, 2015 at 1:56 AM, Yasuo Ohgaki 
>>> wrote:
>>>
 Hi Dmitry and Joe,

 On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki 
 wrote:

> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov 
> wrote:
>
>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>> It looks like we have similar views, so just make it better in a way
>> you think.
>>
>
> Looks good to me. It's much better than original. Thank you folks.
> We have related issue like how internal module incorporate with DbC.
> However
> these could be future issues.
>

 A little more clarification,  following interface definition is allowed
 or not?

 interface Some {

   require($this->last_result > 1000); // Force classes to have
 $this->result

   function bar($a, $b)
  require($a > $b)
  return($ret, $ret > 1000);

   function getLastResult()
  return($ret, $this->last_result === $ret);

 }

 I suppose it is supported, but it may be better to be explicit.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net

>>>
>>>
>>
>

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

So, I think we have to support them as well.

On Wed, Feb 11, 2015 at 10:12 AM, Yasuo Ohgaki  wrote:

> Hi Dmitry and Joe,
>
> On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov  wrote:
>
>> I think we can't support contracts on interfaces and abstract methods.
>> How D works?
>
>
> D supports contract in structure and interface. Structure is more like
> classes in D, though.
>
> interface I
> {
> int foo(int i)
> in { assert(i > 7); }
> out (result) { assert(result & 1); }
>
> void bar();
> }
>
> http://dlang.org/interface.html
>
>
> Eiffel support contracts for interfaces.
>
>   class interface DICTIONARY [ELEMENT] feature
>
>put (x: ELEMENT; key: STRING) is
> -- Insert x so that it will be retrievable
>-- through key.
>   require
>   count <= capacity
>   not key.empty
>ensure
>   has (x)
>   item (key) = x
>   count = old count + 1
>
> ... Interface specifications of other features ...
>
>   invariant
>
> 0 <= count
> count <= capacity
>
>   end -- class interface DICTIONARY
>
>
> https://archive.eiffel.com/doc/manuals/technology/contract/
>
> If there is no technical difficulties, I would like to have it.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

it's possible to achieve the same validation just with assert() spread over
the code.
It's nothing wrong with this, but this is not DbC.

The question, if we need DbC at all, is still open.

Thanks. Dmitry.

On Wed, Feb 11, 2015 at 10:05 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > Hello, internals!
> >
> > DbC is good thing, but the way you want to do this via language changes
> is
> > really awful. Why do you want to add more custom features into the
>
> Agreed here. I still don't see what's wrong with just putting the code
> at the beginning of the function and whenever you want to check it. Why
> this need to change the language syntax? OK, you don't like assert
> because it's limited or performance-costly or whatever. We can fix that.
> Why we need weird syntax that places function code in three different
> places, reuses existing syntax constructs for things that have nothing
> to do with their original use and look like Perl YAPH signature? I
> understand implementing fashionable concepts is fun, but must they come
> with weird syntax? Why can't we keep it simple?
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

I think we should just repeat the related D semantic.
It must be defined in contracts inheritance rules.

What if we have contracts for prototype method in parent class and
interface?
Should we still validate contracts of parent and interface if we add our
owns?
etc.

Thanks. Dmitry.

On Wed, Feb 11, 2015 at 10:08 AM, Joe Watkins  wrote:

> D has them:
>
> http://dlang.org/interface.html#interface-contracts
>
> Maybe we could allow pre/post contracts but invariants don't make sense on
> interfaces.
>
> The question is, do we want to make them always available when possible,
> or do we want to make them available where it seems most useful and or
> least complex ?
>
> I prefer the latter, everyone else ?
>
> Cheers
> Joe
>
> On Wed, Feb 11, 2015 at 7:02 AM, Dmitry Stogov  wrote:
>
>> I think we can't support contracts on interfaces and abstract methods.
>> How D works?
>>
>> Thanks. Dmitry.
>>
>> On Wed, Feb 11, 2015 at 1:56 AM, Yasuo Ohgaki  wrote:
>>
>>> Hi Dmitry and Joe,
>>>
>>> On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki 
>>> wrote:
>>>
 On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:

> You are welcome to edit https://wiki.php.net/rfc/dbc2
> It looks like we have similar views, so just make it better in a way
> you think.
>

 Looks good to me. It's much better than original. Thank you folks.
 We have related issue like how internal module incorporate with DbC.
 However
 these could be future issues.

>>>
>>> A little more clarification,  following interface definition is allowed
>>> or not?
>>>
>>> interface Some {
>>>
>>>   require($this->last_result > 1000); // Force classes to have
>>> $this->result
>>>
>>>   function bar($a, $b)
>>>  require($a > $b)
>>>  return($ret, $ret > 1000);
>>>
>>>   function getLastResult()
>>>  return($ret, $this->last_result === $ret);
>>>
>>> }
>>>
>>> I suppose it is supported, but it may be better to be explicit.
>>>
>>> Regards,
>>>
>>> --
>>> Yasuo Ohgaki
>>> yohg...@ohgaki.net
>>>
>>
>>
>

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

Hi Stas,

I agree, it may look weird at first, but if you familiar with concept it
looks more or less natural. It's implemented in D, Effiel, it was a
proposal for Java, etc

Anyway, we will have at least 3 competing proposals.

1) contracts in doc-commetns https://wiki.php.net/rfc/dbc

/**
 * @requires ($a >= 0)
 */
function foo($a) {
}

2) contracts as part of the language https://wiki.php.net/rfc/dbc2

function foo($a)
require($a >= 0)
{
}

3) contracts in annotations

<= 0)>>
function foo($a) {
}

The fact that we are working on (2) now, doesn't mean we will select it as
a final solution. (3) is an interesting option as well.

Thanks. Dmitry.

On Wed, Feb 11, 2015 at 9:56 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > Please steer clear of using the assert API, and in so doing avoid BC
> > concerns with the current assert API.
>
> The operator can be called something other than "assert", I'm sure the
> thesaurus has a lot of possibilities.
>
> > Please avoid adding a magic method and use the suggested syntax for
> > invariant.
> >
> > class Some {
> > require(invariant-expr);
>
> I think reusing syntax for existing operator in completely unrelated
> context is a big mistake. Having code outside of functions is probably
> not the best idea too.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> If there is no technical difficulties, I would like to have it.

Okay then, I'll rethink ...

Cheers
Joe

On Wed, Feb 11, 2015 at 7:12 AM, Yasuo Ohgaki  wrote:

> Hi Dmitry and Joe,
>
> On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov  wrote:
>
>> I think we can't support contracts on interfaces and abstract methods.
>> How D works?
>
>
> D supports contract in structure and interface. Structure is more like
> classes in D, though.
>
> interface I
> {
> int foo(int i)
> in { assert(i > 7); }
> out (result) { assert(result & 1); }
>
> void bar();
> }
>
> http://dlang.org/interface.html
>
>
> Eiffel support contracts for interfaces.
>
>   class interface DICTIONARY [ELEMENT] feature
>
>put (x: ELEMENT; key: STRING) is
> -- Insert x so that it will be retrievable
>-- through key.
>   require
>   count <= capacity
>   not key.empty
>ensure
>   has (x)
>   item (key) = x
>   count = old count + 1
>
> ... Interface specifications of other features ...
>
>   invariant
>
> 0 <= count
> count <= capacity
>
>   end -- class interface DICTIONARY
>
>
> https://archive.eiffel.com/doc/manuals/technology/contract/
>
> If there is no technical difficulties, I would like to have it.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> I still don't see what's wrong with just putting the code
at the beginning of the function and whenever you want to check it

That makes inheritance of contracts awkward/impossible/impractical:

class Some {
public function method() {
assertOrWhatever($expr);
}
}

class Other extends Some {
public function method() {

}
}

The implementation of Other::method cannot inherit or otherwise make use of
the contracts made by Some.

Putting invariants in the class scope and pre/post conditions in the
function prototype makes inheritance relatively easy.

This seems to answer all your questions.

Cheers
Joe

On Wed, Feb 11, 2015 at 7:11 AM, Joe Watkins  wrote:

> > I think reusing syntax for existing operator in completely unrelated
> context is a big mistake.
>
> I keep hearing that, I agree, but adding keywords presents it's own
> problems.
>
> The keywords can always be changed, maybe they can be a voting option even.
>
> Cheers
> Joe
>
> On Wed, Feb 11, 2015 at 6:56 AM, Stanislav Malyshev 
> wrote:
>
>> Hi!
>>
>> > Please steer clear of using the assert API, and in so doing avoid BC
>> > concerns with the current assert API.
>>
>> The operator can be called something other than "assert", I'm sure the
>> thesaurus has a lot of possibilities.
>>
>> > Please avoid adding a magic method and use the suggested syntax for
>> > invariant.
>> >
>> > class Some {
>> > require(invariant-expr);
>>
>> I think reusing syntax for existing operator in completely unrelated
>> context is a big mistake. Having code outside of functions is probably
>> not the best idea too.
>>
>> --
>> Stas Malyshev
>> smalys...@gmail.com
>>
>
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry and Joe,

On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov  wrote:

> I think we can't support contracts on interfaces and abstract methods.
> How D works?


D supports contract in structure and interface. Structure is more like
classes in D, though.

interface I
{
int foo(int i)
in { assert(i > 7); }
out (result) { assert(result & 1); }

void bar();
}

http://dlang.org/interface.html


Eiffel support contracts for interfaces.

  class interface DICTIONARY [ELEMENT] feature

   put (x: ELEMENT; key: STRING) is
-- Insert x so that it will be retrievable
   -- through key.
  require
  count <= capacity
  not key.empty
   ensure
  has (x)
  item (key) = x
  count = old count + 1

... Interface specifications of other features ...

  invariant

0 <= count
count <= capacity

  end -- class interface DICTIONARY


https://archive.eiffel.com/doc/manuals/technology/contract/

If there is no technical difficulties, I would like to have it.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> I think reusing syntax for existing operator in completely unrelated
context is a big mistake.

I keep hearing that, I agree, but adding keywords presents it's own
problems.

The keywords can always be changed, maybe they can be a voting option even.

Cheers
Joe

On Wed, Feb 11, 2015 at 6:56 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > Please steer clear of using the assert API, and in so doing avoid BC
> > concerns with the current assert API.
>
> The operator can be called something other than "assert", I'm sure the
> thesaurus has a lot of possibilities.
>
> > Please avoid adding a magic method and use the suggested syntax for
> > invariant.
> >
> > class Some {
> > require(invariant-expr);
>
> I think reusing syntax for existing operator in completely unrelated
> context is a big mistake. Having code outside of functions is probably
> not the best idea too.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

D has them:

http://dlang.org/interface.html#interface-contracts

Maybe we could allow pre/post contracts but invariants don't make sense on
interfaces.

The question is, do we want to make them always available when possible, or
do we want to make them available where it seems most useful and or least
complex ?

I prefer the latter, everyone else ?

Cheers
Joe

On Wed, Feb 11, 2015 at 7:02 AM, Dmitry Stogov  wrote:

> I think we can't support contracts on interfaces and abstract methods.
> How D works?
>
> Thanks. Dmitry.
>
> On Wed, Feb 11, 2015 at 1:56 AM, Yasuo Ohgaki  wrote:
>
>> Hi Dmitry and Joe,
>>
>> On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki  wrote:
>>
>>> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:
>>>
 You are welcome to edit https://wiki.php.net/rfc/dbc2
 It looks like we have similar views, so just make it better in a way
 you think.

>>>
>>> Looks good to me. It's much better than original. Thank you folks.
>>> We have related issue like how internal module incorporate with DbC.
>>> However
>>> these could be future issues.
>>>
>>
>> A little more clarification,  following interface definition is allowed
>> or not?
>>
>> interface Some {
>>
>>   require($this->last_result > 1000); // Force classes to have
>> $this->result
>>
>>   function bar($a, $b)
>>  require($a > $b)
>>  return($ret, $ret > 1000);
>>
>>   function getLastResult()
>>  return($ret, $this->last_result === $ret);
>>
>> }
>>
>> I suppose it is supported, but it may be better to be explicit.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>
>

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

Got it, but currently we don't declare internal classes/interfaces in PHP.
We do it with internal C API, of course we may extend it to support
contracts, but it looks too complex for C.
It's easier to make all necessary validation directly in C code.
I don't think we should propose something related now.

Thanks. Dmitry.

On Wed, Feb 11, 2015 at 6:01 AM, Yasuo Ohgaki  wrote:

> Hi Dmitry and Joe,
>
> On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki  wrote:
>
>> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:
>>
>>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>>> It looks like we have similar views, so just make it better in a way you
>>> think.
>>>
>>
>> Looks good to me. It's much better than original. Thank you folks.
>> We have related issue like how internal module incorporate with DbC.
>> However
>> these could be future issues.
>>
>
> I would like explain one of the reason why I bring up internal module.
>
> http://php.net/manual/en/class.sessionhandlerinterface.php
>
> Session has internal interface definitions like
>
> SessionHandlerInterface {
>   /* Methods */
>   abstract public bool close ( void )
>   abstract public bool destroy ( string $session_id )
>   abstract public bool gc ( string $maxlifetime )
>   abstract public bool open ( string $save_path , string $name )
>   abstract public string read ( string $session_id )
>   abstract public bool write ( string $session_id , string $session_data )
> }
>
> but it should be like follows to be precise.
>
> SessionHandlerInterface {
>   /* Methods */
>   abstract public bool close ( void )
> return($ret, is_bool($ret));
>
>   abstract public bool destroy ( string $session_id )
> require(strlen($session_id) > 0)
> return($ret, is_bool($ret));
>
>   abstract public bool gc ( string $maxlifetime )
> require($maxlifetime >= 0)
> return($ret, is_int($ret) && $ret >= -1);
>
>   abstract public bool open ( string $save_path , string $name )
> require(is_string($save_path))
> require(is_string($name));
> return($ret, is_bool($ret));
>
>   abstract public string read ( string $session_id )
> require(strlen($session_id) > 0)
> return($ret, is_bool($ret) || is_string($ret));
>
>   abstract public bool write ( string $session_id , string $session_data )
> require(is_string($session_id) && strlen($session_id) > 0)
> require(is_string($session_data))
> return($ret, is_bool($ret));
> }
>
> This definition is more user friendly. There were too many user save
> handlers
> that do not return proper values because of current interface limitation.
>
> Scalar type and return type hint helps, but it does not cover
>
> return($ret, is_int($ret) && $ret >= -1);
>
> for example.
>
> If you think this is easy to implement and should be in the RFC, I would
> appreciated it
> and use it to raise assertion errors just like user class/interface.
>
> BTW, these restrictions are coded as error in current session module and
> should
> be checked by the module always. It's not mandatory for the RFC, but just
> a missing piece.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>

Re: [PHP-DEV] Design by Contract

[Stanislav Malyshev]

Hi!

> Hello, internals!
> 
> DbC is good thing, but the way you want to do this via language changes is
> really awful. Why do you want to add more custom features into the

Agreed here. I still don't see what's wrong with just putting the code
at the beginning of the function and whenever you want to check it. Why
this need to change the language syntax? OK, you don't like assert
because it's limited or performance-costly or whatever. We can fix that.
Why we need weird syntax that places function code in three different
places, reuses existing syntax constructs for things that have nothing
to do with their original use and look like Perl YAPH signature? I
understand implementing fashionable concepts is fun, but must they come
with weird syntax? Why can't we keep it simple?

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

I think we can't support contracts on interfaces and abstract methods.
How D works?

Thanks. Dmitry.

On Wed, Feb 11, 2015 at 1:56 AM, Yasuo Ohgaki  wrote:

> Hi Dmitry and Joe,
>
> On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki  wrote:
>
>> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:
>>
>>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>>> It looks like we have similar views, so just make it better in a way you
>>> think.
>>>
>>
>> Looks good to me. It's much better than original. Thank you folks.
>> We have related issue like how internal module incorporate with DbC.
>> However
>> these could be future issues.
>>
>
> A little more clarification,  following interface definition is allowed or
> not?
>
> interface Some {
>
>   require($this->last_result > 1000); // Force classes to have
> $this->result
>
>   function bar($a, $b)
>  require($a > $b)
>  return($ret, $ret > 1000);
>
>   function getLastResult()
>  return($ret, $this->last_result === $ret);
>
> }
>
> I suppose it is supported, but it may be better to be explicit.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> I didn't get what do you mean by " internal module"

He means extension, builtin classes/functions.

Cheers
Joe

On Wed, Feb 11, 2015 at 7:00 AM, Dmitry Stogov  wrote:

> I didn't get what do you mean by " internal module"
>
> Thanks. Dmitry.
>
> On Wed, Feb 11, 2015 at 12:29 AM, Yasuo Ohgaki  wrote:
>
>> Hi Dmitry and Joe,
>>
>> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:
>>
>>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>>> It looks like we have similar views, so just make it better in a way you
>>> think.
>>>
>>
>> Looks good to me. It's much better than original. Thank you folks.
>> We have related issue like how internal module incorporate with DbC.
>> However
>> these could be future issues.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>
>

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

I didn't get what do you mean by " internal module"

Thanks. Dmitry.

On Wed, Feb 11, 2015 at 12:29 AM, Yasuo Ohgaki  wrote:

> Hi Dmitry and Joe,
>
> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:
>
>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>> It looks like we have similar views, so just make it better in a way you
>> think.
>>
>
> Looks good to me. It's much better than original. Thank you folks.
> We have related issue like how internal module incorporate with DbC.
> However
> these could be future issues.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Design by Contract

[Stanislav Malyshev]

Hi!

> Please steer clear of using the assert API, and in so doing avoid BC
> concerns with the current assert API.

The operator can be called something other than "assert", I'm sure the
thesaurus has a lot of possibilities.

> Please avoid adding a magic method and use the suggested syntax for
> invariant.
> 
> class Some {
> require(invariant-expr);

I think reusing syntax for existing operator in completely unrelated
context is a big mistake. Having code outside of functions is probably
not the best idea too.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> We have related issue like how internal module incorporate with DbC.
However
these could be future issues.

I think this should be an additional RFC, so we'll put this under future
issues I think.

> A little more clarification,  following interface definition is allowed
or not?

Currently, we're saying that abstract functions (and interface functions)
may not use contracts.

Since interface methods are abstract functions, and abstract functions do
no have a body, it doesn't seem to make sense to allow them to use
contracts.

The contracts are supposed to purtain to the body of the function, or the
body of all functions in a class in the case of invariants: No body, no
contracts.

I'll make this clear ...

I'll work a bit more on the RFC today ...

Cheers
Joe

On Wed, Feb 11, 2015 at 3:01 AM, Yasuo Ohgaki  wrote:

> Hi Dmitry and Joe,
>
> On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki  wrote:
>
>> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:
>>
>>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>>> It looks like we have similar views, so just make it better in a way you
>>> think.
>>>
>>
>> Looks good to me. It's much better than original. Thank you folks.
>> We have related issue like how internal module incorporate with DbC.
>> However
>> these could be future issues.
>>
>
> I would like explain one of the reason why I bring up internal module.
>
> http://php.net/manual/en/class.sessionhandlerinterface.php
>
> Session has internal interface definitions like
>
> SessionHandlerInterface {
>   /* Methods */
>   abstract public bool close ( void )
>   abstract public bool destroy ( string $session_id )
>   abstract public bool gc ( string $maxlifetime )
>   abstract public bool open ( string $save_path , string $name )
>   abstract public string read ( string $session_id )
>   abstract public bool write ( string $session_id , string $session_data )
> }
>
> but it should be like follows to be precise.
>
> SessionHandlerInterface {
>   /* Methods */
>   abstract public bool close ( void )
> return($ret, is_bool($ret));
>
>   abstract public bool destroy ( string $session_id )
> require(strlen($session_id) > 0)
> return($ret, is_bool($ret));
>
>   abstract public bool gc ( string $maxlifetime )
> require($maxlifetime >= 0)
> return($ret, is_int($ret) && $ret >= -1);
>
>   abstract public bool open ( string $save_path , string $name )
> require(is_string($save_path))
> require(is_string($name));
> return($ret, is_bool($ret));
>
>   abstract public string read ( string $session_id )
> require(strlen($session_id) > 0)
> return($ret, is_bool($ret) || is_string($ret));
>
>   abstract public bool write ( string $session_id , string $session_data )
> require(is_string($session_id) && strlen($session_id) > 0)
> require(is_string($session_data))
> return($ret, is_bool($ret));
> }
>
> This definition is more user friendly. There were too many user save
> handlers
> that do not return proper values because of current interface limitation.
>
> Scalar type and return type hint helps, but it does not cover
>
> return($ret, is_int($ret) && $ret >= -1);
>
> for example.
>
> If you think this is easy to implement and should be in the RFC, I would
> appreciated it
> and use it to raise assertion errors just like user class/interface.
>
> BTW, these restrictions are coded as error in current session module and
> should
> be checked by the module always. It's not mandatory for the RFC, but just
> a missing piece.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry and Joe,

On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki  wrote:

> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:
>
>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>> It looks like we have similar views, so just make it better in a way you
>> think.
>>
>
> Looks good to me. It's much better than original. Thank you folks.
> We have related issue like how internal module incorporate with DbC.
> However
> these could be future issues.
>

I would like explain one of the reason why I bring up internal module.

http://php.net/manual/en/class.sessionhandlerinterface.php

Session has internal interface definitions like

SessionHandlerInterface {
  /* Methods */
  abstract public bool close ( void )
  abstract public bool destroy ( string $session_id )
  abstract public bool gc ( string $maxlifetime )
  abstract public bool open ( string $save_path , string $name )
  abstract public string read ( string $session_id )
  abstract public bool write ( string $session_id , string $session_data )
}

but it should be like follows to be precise.

SessionHandlerInterface {
  /* Methods */
  abstract public bool close ( void )
return($ret, is_bool($ret));

  abstract public bool destroy ( string $session_id )
require(strlen($session_id) > 0)
return($ret, is_bool($ret));

  abstract public bool gc ( string $maxlifetime )
require($maxlifetime >= 0)
return($ret, is_int($ret) && $ret >= -1);

  abstract public bool open ( string $save_path , string $name )
require(is_string($save_path))
require(is_string($name));
return($ret, is_bool($ret));

  abstract public string read ( string $session_id )
require(strlen($session_id) > 0)
return($ret, is_bool($ret) || is_string($ret));

  abstract public bool write ( string $session_id , string $session_data )
require(is_string($session_id) && strlen($session_id) > 0)
require(is_string($session_data))
return($ret, is_bool($ret));
}

This definition is more user friendly. There were too many user save
handlers
that do not return proper values because of current interface limitation.

Scalar type and return type hint helps, but it does not cover

return($ret, is_int($ret) && $ret >= -1);

for example.

If you think this is easy to implement and should be in the RFC, I would
appreciated it
and use it to raise assertion errors just like user class/interface.

BTW, these restrictions are coded as error in current session module and
should
be checked by the module always. It's not mandatory for the RFC, but just a
missing piece.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry and Joe,

On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki  wrote:

> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:
>
>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>> It looks like we have similar views, so just make it better in a way you
>> think.
>>
>
> Looks good to me. It's much better than original. Thank you folks.
> We have related issue like how internal module incorporate with DbC.
> However
> these could be future issues.
>

A little more clarification,  following interface definition is allowed or
not?

interface Some {

  require($this->last_result > 1000); // Force classes to have $this->result

  function bar($a, $b)
 require($a > $b)
 return($ret, $ret > 1000);

  function getLastResult()
 return($ret, $this->last_result === $ret);

}

I suppose it is supported, but it may be better to be explicit.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry and Joe,

On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki  wrote:

> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:
>
>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>> It looks like we have similar views, so just make it better in a way you
>> think.
>>
>
> Looks good to me. It's much better than original. Thank you folks.
> We have related issue like how internal module incorporate with DbC.
> However
> these could be future issues.
>

It seems we are better to have scope explanation. precondition/invariant
does not
matter but postcondition is. For example,

function foo() {
   return($ret, $ret > 0 && $tmp > 0, 'Error');
   $tmp = 0;
// do something using $tmp
}

if this is allowed or not is ambiguous.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry and Joe,

On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov  wrote:

> You are welcome to edit https://wiki.php.net/rfc/dbc2
> It looks like we have similar views, so just make it better in a way you
> think.
>

Looks good to me. It's much better than original. Thank you folks.
We have related issue like how internal module incorporate with DbC. However
these could be future issues.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Benoit SCHILDKNECHT]

Hi Yasuo,

Le Tue, 10 Feb 2015 07:25:00 +0100, Yasuo Ohgaki  a  
écrit:

Updated wiki page.
https://wiki.php.net/rfc/dbc2


While I agree this RFC is going in the right direction, I don't like the  
use of "require" and "return".


They are already used for something completely different, I think it will  
make the code more difficult to understand (for beginners) and parse (for  
external programs). IDE will have some difficulties too. I've discussed  
about it with some PHP developers who work with me, and they all agree.


If it was me, I would use "pre" and "post", "in" and "out" or "requires"  
and "ensures". I understand that creating more keywords isn't something  
pleasant, but it would make the code more readable and logical.


Regards,
Benoit.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Design by Contract

[F & N Laupretre]

Hi Alexander,

> De : Alexander Lisachenko [mailto:lisachenko...@gmail.com]
> 
> This is built on top of reflection+annotation+parser extension.
> Why not to implement this for PHP? From my point of view, this is just an
> additional feature, that can be used by limited number of developers.

I like the idea. IMO, DbC directives should be defined outside of function 
body. I proposed doc blocks because it exists and is already parsed but a 
generic syntax for annotations along with a full API to interact with 
extensions would be much better.

Most important : if we define that, for example, everything outside of a 
class/function enclosed in [], is an annotation, it is easy to enhance PHP 5 to 
ignore such syntax, without having to backport the whole feature. So, people 
can start using it for PHP 7 and keep the possibility to run their code under 
PHP 5. That's something that would be much harder with the current dbc2 
proposal.

I will modify my RFC (https://wiki.php.net/rfc/dbc) to open it to any sort of 
annotations.

Do you think you have enough time to write something in due time ? Ask for help 
if you need.

Regards

François





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Alexander Lisachenko]

2015-02-10 15:35 GMT+03:00 Pavel Kouřil :

> Hello,
>
> maybe you could try to consult your ideas with Ivan Enderlin. He
> mentioned in previous emails (for instance
> http://news.php.net/php.internals/82245) that he would prefer some
> AOP/hook-based approach to DbC as well, so it may be compatible with
> your mindset.
>

Yes, I know about Praspel, it's quite a good implementation, but for
specific case. My implementation of DbC is built on top of AOP and can be
described with only one (!) aspect and few annotations. If you are
interested in it, you could look across wiki
https://github.com/lisachenko/php-deal/wiki or even open an aspect class
itself
https://github.com/lisachenko/php-deal/blob/master/src/PhpDeal/Aspect/ContractCheckerAspect.php
to see an advices that will be triggered as custom hooks before/after or
around original method invocations.

I think, that AOP-based solution is pretty nice: it's only for development
mode. Annotations are not parsed for production mode and looks like a good
documentation, this can be improved later with BDD (Gherkin) to define a
contracts in human-readable format.

@Contract\Verify("Given $amount is positive")
@Contract\Ensure("Result is changed from $old to $old+$amount")

So, it can be a good idea to discuss this topic with Ivan Enderlin. Maybe
he can help me with RFC too.

Re: [PHP-DEV] Design by Contract

[Pavel Kouřil]

On Tue, Feb 10, 2015 at 1:30 PM, Alexander Lisachenko
 wrote:
> 2015-02-10 15:20 GMT+03:00 Dmitry Stogov :
>
>> I thought about this way, and you are welcome to start composing another
>> RFC. it makes sense and has its advantages.
>> Unfortunately, it relays on many unavailable features that has to be
>> designed as well (annotations, AST manipulation, opcode manipulation), but
>> may be this is a right road.
>>
>
>
> Thanks, Dmitry! Your position is clearly highlight my vision, it's not so
> easy, but maybe it will bring us much more profit at the end.
>
>
> 2015-02-10 15:20 GMT+03:00 Dmitry Stogov :
>
>> D and Effiel approach may work as well, but if you like another
>> (annotation based) approach - be involved into development.
>> At first we'll need 3-rd RFC that defines all the things that must be
>> implemented.
>> I may help, with RFC, design and implementation.
>>
>
> Thanks, your help is really appreciated ) I'l try to start another one RFC
> about this API, let's have a look what can be done.

Hello,

maybe you could try to consult your ideas with Ivan Enderlin. He
mentioned in previous emails (for instance
http://news.php.net/php.internals/82245) that he would prefer some
AOP/hook-based approach to DbC as well, so it may be compatible with
your mindset.

Regards
Pavel Kouril

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Alexander Lisachenko]

2015-02-10 15:20 GMT+03:00 Dmitry Stogov :

> I thought about this way, and you are welcome to start composing another
> RFC. it makes sense and has its advantages.
> Unfortunately, it relays on many unavailable features that has to be
> designed as well (annotations, AST manipulation, opcode manipulation), but
> may be this is a right road.
>


Thanks, Dmitry! Your position is clearly highlight my vision, it's not so
easy, but maybe it will bring us much more profit at the end.


2015-02-10 15:20 GMT+03:00 Dmitry Stogov :

> D and Effiel approach may work as well, but if you like another
> (annotation based) approach - be involved into development.
> At first we'll need 3-rd RFC that defines all the things that must be
> implemented.
> I may help, with RFC, design and implementation.
>

Thanks, your help is really appreciated ) I'l try to start another one RFC
about this API, let's have a look what can be done.

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

Hi Alexander,

On Tue, Feb 10, 2015 at 2:44 PM, Alexander Lisachenko <
lisachenko...@gmail.com> wrote:

> Hello, internals!
>
> DbC is good thing, but the way you want to do this via language changes is
> really awful. Why do you want to add more custom features into the
> language, instead of providing an API to extend it in a more natural way by
> framework developers?
>
>
First of all, I know that you have something working, so your opinion and
suggestions are important for us.

I already told that currently we are in a brainstorming phase
We already have two drafts:

https://wiki.php.net/rfc/dbc(doc-comment based)
https://wiki.php.net/rfc/dbc2   (inspired by D language)

both have their pros and cons.


> Many existing implementation of DbC is just kind of bytecode compilers and
> IDE tools. Main idea of DbC is to help developer with writing a better code
> without errors. But then, during compiling (production mode) all checks
> will be removed.
>

this should be implemented with zero-cost assert proposed long time ago
https://wiki.php.net/rfc/expectations


>
> Am I one who think that this code is looking weird?
>
> public function destroy($id)
> require(strlen($id) > 10)
> return(is_bool($>))
> {
> @unlink($this->path . $id);
> }
>
>
For me it's quite readable.


>
> This part of code is breaks block structure of function, adding custom
> part of code, which is not related to the function logic itself.
>
> Instead of doing this weird syntax only for personal fun, just think
> about more general usages of parser and assertions.
> As you know, I'm working with aspect-oriented programming in PHP and
> have a library for that. And it wasn't easy to implement it, because
> there is no API for that from PHP. This techniques can be also used
> for DbC as well.
>
So, my suggestion is to drop current rfc and start more general one,
> called "PHP Language Extension API", which will include an API for
> defining metadata and API for opcode manipulation. Compare previous
> example with another one with plain metadata:
>
> [Require => strlen($id) > 10)]
> [Return => is_bool($__result))
> public function destroy($id)
> {
> @unlink($this->path . $id);
> }
>

for me it's less readable, but this is a general solution that may be
reused for other features. So, it's interesting.


>
> This code then will be parsed and PHP hooks that were registered by
> register_parser_extension() will be called and extension will
> produce a valid opcodes for that for method destroy(), by modifying
> AST-node.
>

I thought about this way, and you are welcome to start composing another
RFC. it makes sense and has its advantages.
Unfortunately, it relays on many unavailable features that has to be
designed as well (annotations, AST manipulation, opcode manipulation), but
may be this is a right road.


> This way is much elegant and can be reused later for many features,
> like Design By Contracts, native SQL support syntax in PHP (LINQ),
> Aspect-Oriented Programming, hooks and much more.
>
> Just stop to create custom features in the engine itself and give this
> work for framework and PHP-extension developers.
>

D and Effiel approach may work as well, but if you like another (annotation
based) approach - be involved into development.
At first we'll need 3-rd RFC that defines all the things that must be
implemented.
I may help, with RFC, design and implementation.

Thanks. Dmitry.


>
>
>
> 2015-02-10 13:32 GMT+03:00 Lester Caine :
>
> > On 09/02/15 23:47, Yasuo Ohgaki wrote:
> > > The RFC draft is ready.
> > > https://wiki.php.net/rfc/dbc2
> >
> > > These contracts are evaluated development time only. Therefore, there
> is
> > no performance penalty with DbC.
> >
> > Sorry but that makes no sense to me at all. If this is something only to
> > use with an IDE then why does it have to have anything that is visible
> > at 'run time'? This seems to be going down the track of "we will be
> > compiling this eventually" and that is just not what PHP *IS* about.
> > These are more hints, but assume that at runtime what they define is not
> > relevant?
> >
> > ALL of this discussion on type hinting how ever it is handled is simply
> > sidestepping the major plus on PHP with associative arrays. I see no
> > point expanding every database record read to 'magic access functions'
> > for multiple variables and it *IS* the scalar values stored in these
> > arrays that needs the 'hint/constraint' control.
> >
> > I am getting even more confused about just what all the different
> > factions are trying to achieve. Yes I know I can totally ignore all of
> > it, but with my current tools losing traction because of all the 'better
> > ways of working' what in my opinion IS the best way to allow different
> > factions to add their own pet style is drowning simple clean solutions
> > such as docblock.
> >
> > --
> > Lester Caine - G8HFL
> > -
> > Contact - ht

Re: [PHP-DEV] Design by Contract

[Alexander Lisachenko]

2015-02-10 15:10 GMT+03:00 Alexander Lisachenko :

> I would like to see a language with good extension API. For now, it's
> almost impossible to extend a parser, even from extension level (however,
> PHP7 will have a hook for that, thanks God).



To understand how it can be implemented, just read about Checker Framework
(Java) http://types.cs.washington.edu/checker-framework/

...The Checker Framework enhances Java’s type system to make it more
powerful and useful. This lets software developers detect and prevent
errors in their Java programs. The Checker Framework includes compiler
plug-ins ("checkers") that find bugs or verify their absence. It also
permits you to write your own compiler plug-ins...

This is built on top of reflection+annotation+parser extension.
Why not to implement this for PHP? From my point of view, this is just an
additional feature, that can be used by limited number of developers.

Re: [PHP-DEV] Design by Contract

[Alexander Lisachenko]

2015-02-10 14:56 GMT+03:00 Patrick Schaaf :

> Ahem. Any open ended API-for-frameworks will A) force me to pick a
> framework and bend to the way it wants these things to look, and B) result
> in fragmentation and incompatibilities for any two pieces of code/library
> developed with different such frameworks in mind. That will be a total mess.



It's another task for another people, typically for standartization group,
like PSR, JSR, PEP, etc. Framework developers should rely on interfaces and
should provide interfaces. For Java world this works (some ideas here
http://java.dzone.com/articles/jsr-305-and-design-contract)

If put all the things into the PHP core, it will become much bigger, more
slower and hard to maintain. Later posts describes EOL for some extensions
and SAPIs, but this place will not be clean, because another custom feature
XXX is landed on free space.

I would like to see a language with good extension API. For now, it's
almost impossible to extend a parser, even from extension level (however,
PHP7 will have a hook for that, thanks God).

Re: [PHP-DEV] Design by Contract

[Patrick Schaaf]

Am 10.02.2015 12:45 schrieb "Alexander Lisachenko" :
>
> DbC is good thing, but the way you want to do this via language changes is
> really awful. Why do you want to add more custom features into the
> language, instead of providing an API to extend it in a more natural way
by
> framework developers?

Ahem. Any open ended API-for-frameworks will A) force me to pick a
framework and bend to the way it wants these things to look, and B) result
in fragmentation and incompatibilities for any two pieces of code/library
developed with different such frameworks in mind. That will be a total mess.

Having it in the language means I can just use it. Unit tests can just use
it, especially the PHP tests themselves. And if and where frameworks think
they need to mess with it, they can surely be given some Reflection API to
have a go at it.

best regards
  Patrick

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

Hi Joe,

You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way you
think.

Thanks. Dmitry.

On Tue, Feb 10, 2015 at 11:49 AM, Joe Watkins  wrote:

> I'm happy to clean up the RFC after Dmitry's changes are merged.
>
> Happy to author some of the content if Yasuo is busy or wants help ?
>
> Cheers
> Joe
>
>
> On Tue, Feb 10, 2015 at 8:29 AM, Dmitry Stogov  wrote:
>
>> A bit updated version of RFC is attached.
>> As I removed more than added, I decided not to put it on wiki before
>> internal agreement.
>> Actually, I would also remove most part of introduction as well, to make
>> RFC more compact and clean.
>>
>> I cnahged $> into $ret, because $> just won't work. Some better solution
>> is welcome.
>>
>> The RFC misses contract inheritance rules. They must be defined
>> separately for preconditions, postconditions and invariants.
>> Yasuo, could you please check, how it's implemented in D and add missing
>> section.
>>
>> We will need English correction after all.
>>
>> Thanks. Dmitry.
>>
>> On Tue, Feb 10, 2015 at 11:19 AM, Dmitry Stogov  wrote:
>>
>>> completely agree. contracts must be permanent.
>>>
>>> Thanks. Dmitry.
>>>
>>> On Tue, Feb 10, 2015 at 10:40 AM, Joe Watkins 
>>> wrote:
>>>
 Example code never works, I can just say that's a bad abstraction,
 vertebrate and invertebrate are distinct and abstraction should reflect
 that.

 Why should we provide a way to change contracts is the question ?

 It doesn't seem to make sense to do that, a derived class should be
 able to define additional contracts, but not change the contracts of it's
 parent.

 Cheers
 Joe

 On Tue, Feb 10, 2015 at 7:36 AM, Yasuo Ohgaki 
 wrote:

> Hi Joe,
>
> On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins 
> wrote:
>
>> Actually I'm not sure it's at all sane to try to override contracts,
>> I'd actually avoid that completely, so no need to name contracts and no
>> need for magic __invariant.
>
>
> For example,
>
> class Animal {
>protected $legs;
>require($legs >= 0);
> }
>
> class Snake extends Animal {
>   // Snake is fine, no leg
> }
>
> class Human extends Animal {
>   // 2 legs. $this->leg === 2
> }
>
> Overriding makes sense for many cases.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>


>>>
>>
>

Re: [PHP-DEV] Design by Contract

[Alexander Lisachenko]

Hello, internals!

DbC is good thing, but the way you want to do this via language changes is
really awful. Why do you want to add more custom features into the
language, instead of providing an API to extend it in a more natural way by
framework developers?

Many existing implementation of DbC is just kind of bytecode compilers and
IDE tools. Main idea of DbC is to help developer with writing a better code
without errors. But then, during compiling (production mode) all checks
will be removed.

Am I one who think that this code is looking weird?

public function destroy($id)
require(strlen ($id) > 10)
return(is_bool ($>))
{
@unlink ($this->path . $id);
}


This part of code is breaks block structure of function, adding custom
part of code, which is not related to the function logic itself.

Instead of doing this weird syntax only for personal fun, just think
about more general usages of parser and assertions.
As you know, I'm working with aspect-oriented programming in PHP and
have a library for that. And it wasn't easy to implement it, because
there is no API for that from PHP. This techniques can be also used
for DbC as well.

So, my suggestion is to drop current rfc and start more general one,
called "PHP Language Extension API", which will include an API for
defining metadata and API for opcode manipulation. Compare previous
example with another one with plain metadata:

[Require => strlen ($id) > 10)]
[Return => is_bool ($__result))
public function destroy($id)
{
@unlink ($this->path . $id);
}

This code then will be parsed and PHP hooks that were registered by
register_parser_extension() will be called and extension will
produce a valid opcodes for that for method destroy(), by modifying AST-node.

This way is much elegant and can be reused later for many features,
like Design By Contracts, native SQL support syntax in PHP (LINQ),
Aspect-Oriented Programming, hooks and much more.

Just stop to create custom features in the engine itself and give this
work for framework and PHP-extension developers.




2015-02-10 13:32 GMT+03:00 Lester Caine :

> On 09/02/15 23:47, Yasuo Ohgaki wrote:
> > The RFC draft is ready.
> > https://wiki.php.net/rfc/dbc2
>
> > These contracts are evaluated development time only. Therefore, there is
> no performance penalty with DbC.
>
> Sorry but that makes no sense to me at all. If this is something only to
> use with an IDE then why does it have to have anything that is visible
> at 'run time'? This seems to be going down the track of "we will be
> compiling this eventually" and that is just not what PHP *IS* about.
> These are more hints, but assume that at runtime what they define is not
> relevant?
>
> ALL of this discussion on type hinting how ever it is handled is simply
> sidestepping the major plus on PHP with associative arrays. I see no
> point expanding every database record read to 'magic access functions'
> for multiple variables and it *IS* the scalar values stored in these
> arrays that needs the 'hint/constraint' control.
>
> I am getting even more confused about just what all the different
> factions are trying to achieve. Yes I know I can totally ignore all of
> it, but with my current tools losing traction because of all the 'better
> ways of working' what in my opinion IS the best way to allow different
> factions to add their own pet style is drowning simple clean solutions
> such as docblock.
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Joe,

On Tue, Feb 10, 2015 at 4:40 PM, Joe Watkins  wrote:

> It doesn't seem to make sense to do that, a derived class should be able
> to define additional contracts, but not change the contracts of it's parent.


I forgot that invariants in D and Eiffel implicitly inherits parent's
invariants.
So classes that causes problems have design bug.

Please go ahead editing the file. I wouldn't have time until next morning.
There will be hours. I'll wait as long as it takes.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Lester Caine]

On 09/02/15 23:47, Yasuo Ohgaki wrote:
> The RFC draft is ready.
> https://wiki.php.net/rfc/dbc2

> These contracts are evaluated development time only. Therefore, there is no 
> performance penalty with DbC. 

Sorry but that makes no sense to me at all. If this is something only to
use with an IDE then why does it have to have anything that is visible
at 'run time'? This seems to be going down the track of "we will be
compiling this eventually" and that is just not what PHP *IS* about.
These are more hints, but assume that at runtime what they define is not
relevant?

ALL of this discussion on type hinting how ever it is handled is simply
sidestepping the major plus on PHP with associative arrays. I see no
point expanding every database record read to 'magic access functions'
for multiple variables and it *IS* the scalar values stored in these
arrays that needs the 'hint/constraint' control.

I am getting even more confused about just what all the different
factions are trying to achieve. Yes I know I can totally ignore all of
it, but with my current tools losing traction because of all the 'better
ways of working' what in my opinion IS the best way to allow different
factions to add their own pet style is drowning simple clean solutions
such as docblock.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> may be something similar to Smaltalk block syntax: return(,
 [, ])

That's a good approximation of perfect, I think ... looks okay to me.

Cheers
Joe

On Tue, Feb 10, 2015 at 10:21 AM, Dmitry Stogov  wrote:

> D uses block syntax:
>
> ensure(ret) {
> }
>
> In this case, passing 'ret' as a 'parameter' looks more or less natural.
>
> In our case, two sets of brackets looks weird.
> Predefined variable or constant looks better.
> A agree, __RETURN__ is longer than $ret, but it also won't conflict with
> other variables.
> I don't see a perfect solution yet.
>
> may be something similar to Smaltalk block syntax: return(,
>  [, ])
>
> function add($a, $b)
> return($ret, $ret > 0)
> {
> return $a + $b;
> }
>
> Thanks. Dmitry.
>
> On Tue, Feb 10, 2015 at 1:03 PM, Joe Watkins 
> wrote:
>
>> The solution D uses is allowing the programmer to declare the name of the
>> return value like, we could do something like:
>>
>> public function method()
>> return ($result) ($result <= 10 && $result >= 0) {
>> return 5;
>> }
>>
>> If you didn't need the result, were working with a scope variable, or
>> maybe even a param taken by reference:
>>
>> public function method()
>>return ($expr) {
>>/* ... */
>> }
>>
>> I'm not keen on __CONSTANTS__, it's long, and if you have the choice to
>> name the variable you have the option of making the expression ...
>> expressive ...
>>
>> Cheers
>> Joe
>>
>> On Tue, Feb 10, 2015 at 9:48 AM, Dmitry Stogov  wrote:
>>
>>> I think __RETURN__ is better than $ret.
>>>
>>> Dmitry.
>>>
>>> On Tue, Feb 10, 2015 at 12:43 PM, Patrick Schaaf  wrote:
>>>
 Am 10.02.2015 09:29 schrieb "Dmitry Stogov" :
 >
 > I cnahged $> into $ret, because $> just won't work. Some better
 solution is welcome.

 Also think $> would be awful. Don't like $ret either. What about a
 magic constant __RETURN__ or __RESULT__? This would stand out very well
 when glancing at the expression, would fit in with naming of other magic
 constants, and might even be made to work in finally blocks, where the same
 need for access to the returned value exists.

 best regards
   Patrick

>>>
>>>
>>
>

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

D uses block syntax:

ensure(ret) {
}

In this case, passing 'ret' as a 'parameter' looks more or less natural.

In our case, two sets of brackets looks weird.
Predefined variable or constant looks better.
A agree, __RETURN__ is longer than $ret, but it also won't conflict with
other variables.
I don't see a perfect solution yet.

may be something similar to Smaltalk block syntax: return(,
 [, ])

function add($a, $b)
return($ret, $ret > 0)
{
return $a + $b;
}

Thanks. Dmitry.

On Tue, Feb 10, 2015 at 1:03 PM, Joe Watkins  wrote:

> The solution D uses is allowing the programmer to declare the name of the
> return value like, we could do something like:
>
> public function method()
> return ($result) ($result <= 10 && $result >= 0) {
> return 5;
> }
>
> If you didn't need the result, were working with a scope variable, or
> maybe even a param taken by reference:
>
> public function method()
>return ($expr) {
>/* ... */
> }
>
> I'm not keen on __CONSTANTS__, it's long, and if you have the choice to
> name the variable you have the option of making the expression ...
> expressive ...
>
> Cheers
> Joe
>
> On Tue, Feb 10, 2015 at 9:48 AM, Dmitry Stogov  wrote:
>
>> I think __RETURN__ is better than $ret.
>>
>> Dmitry.
>>
>> On Tue, Feb 10, 2015 at 12:43 PM, Patrick Schaaf  wrote:
>>
>>> Am 10.02.2015 09:29 schrieb "Dmitry Stogov" :
>>> >
>>> > I cnahged $> into $ret, because $> just won't work. Some better
>>> solution is welcome.
>>>
>>> Also think $> would be awful. Don't like $ret either. What about a magic
>>> constant __RETURN__ or __RESULT__? This would stand out very well when
>>> glancing at the expression, would fit in with naming of other magic
>>> constants, and might even be made to work in finally blocks, where the same
>>> need for access to the returned value exists.
>>>
>>> best regards
>>>   Patrick
>>>
>>
>>
>

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> $this->a = require(> 100);

This is already valid-ish code ..

On Tue, Feb 10, 2015 at 9:56 AM, Robert Stoll  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 
> 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 
> wrote:
> > >
> > >> Hi,
> > >>
> > >> can I make some minor correction?
> > >>
> > >> Thanks. Dmitry.
> > >>
> > >>
> > >>
> > >> On Tue, Feb 10, 2015 at 9:25 AM, Yasuo Ohgaki 
> wrote:
> > >>
> > >>> Hi Dmitry,
> > >>>
> > >>> On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov 
> wrote:
> > >>>
> > >>>> On Feb 9, 2015 11:20 PM, "Yasuo Ohgaki"  wrote:
> > >>>> >
> > >>>> > Hi Dmitry and Joe,
> > >>>> >
> > >>>> > On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov 
> > >>>> 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
> > >>>> >> 
> > >>>> 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

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

The solution D uses is allowing the programmer to declare the name of the
return value like, we could do something like:

public function method()
return ($result) ($result <= 10 && $result >= 0) {
return 5;
}

If you didn't need the result, were working with a scope variable, or maybe
even a param taken by reference:

public function method()
   return ($expr) {
   /* ... */
}

I'm not keen on __CONSTANTS__, it's long, and if you have the choice to
name the variable you have the option of making the expression ...
expressive ...

Cheers
Joe

On Tue, Feb 10, 2015 at 9:48 AM, Dmitry Stogov  wrote:

> I think __RETURN__ is better than $ret.
>
> Dmitry.
>
> On Tue, Feb 10, 2015 at 12:43 PM, Patrick Schaaf  wrote:
>
>> Am 10.02.2015 09:29 schrieb "Dmitry Stogov" :
>> >
>> > I cnahged $> into $ret, because $> just won't work. Some better
>> solution is welcome.
>>
>> Also think $> would be awful. Don't like $ret either. What about a magic
>> constant __RETURN__ or __RESULT__? This would stand out very well when
>> glancing at the expression, would fit in with naming of other magic
>> constants, and might even be made to work in finally blocks, where the same
>> need for access to the returned value exists.
>>
>> best regards
>>   Patrick
>>
>
>

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

I think __RETURN__ is better than $ret.

Dmitry.

On Tue, Feb 10, 2015 at 12:43 PM, Patrick Schaaf  wrote:

> Am 10.02.2015 09:29 schrieb "Dmitry Stogov" :
> >
> > I cnahged $> into $ret, because $> just won't work. Some better solution
> is welcome.
>
> Also think $> would be awful. Don't like $ret either. What about a magic
> constant __RETURN__ or __RESULT__? This would stand out very well when
> glancing at the expression, would fit in with naming of other magic
> constants, and might even be made to work in finally blocks, where the same
> need for access to the returned value exists.
>
> best regards
>   Patrick
>

Re: [PHP-DEV] Design by Contract

[Patrick Schaaf]

Am 10.02.2015 09:29 schrieb "Dmitry Stogov" :
>
> I cnahged $> into $ret, because $> just won't work. Some better solution
is welcome.

Also think $> would be awful. Don't like $ret either. What about a magic
constant __RETURN__ or __RESULT__? This would stand out very well when
glancing at the expression, would fit in with naming of other magic
constants, and might even be made to work in finally blocks, where the same
need for access to the returned value exists.

best regards
  Patrick

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

I'm happy to clean up the RFC after Dmitry's changes are merged.

Happy to author some of the content if Yasuo is busy or wants help ?

Cheers
Joe

On Tue, Feb 10, 2015 at 8:29 AM, Dmitry Stogov  wrote:

> A bit updated version of RFC is attached.
> As I removed more than added, I decided not to put it on wiki before
> internal agreement.
> Actually, I would also remove most part of introduction as well, to make
> RFC more compact and clean.
>
> I cnahged $> into $ret, because $> just won't work. Some better solution
> is welcome.
>
> The RFC misses contract inheritance rules. They must be defined separately
> for preconditions, postconditions and invariants.
> Yasuo, could you please check, how it's implemented in D and add missing
> section.
>
> We will need English correction after all.
>
> Thanks. Dmitry.
>
> On Tue, Feb 10, 2015 at 11:19 AM, Dmitry Stogov  wrote:
>
>> completely agree. contracts must be permanent.
>>
>> Thanks. Dmitry.
>>
>> On Tue, Feb 10, 2015 at 10:40 AM, Joe Watkins 
>> wrote:
>>
>>> Example code never works, I can just say that's a bad abstraction,
>>> vertebrate and invertebrate are distinct and abstraction should reflect
>>> that.
>>>
>>> Why should we provide a way to change contracts is the question ?
>>>
>>> It doesn't seem to make sense to do that, a derived class should be able
>>> to define additional contracts, but not change the contracts of it's parent.
>>>
>>> Cheers
>>> Joe
>>>
>>> On Tue, Feb 10, 2015 at 7:36 AM, Yasuo Ohgaki 
>>> wrote:
>>>
 Hi Joe,

 On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins 
 wrote:

> Actually I'm not sure it's at all sane to try to override contracts,
> I'd actually avoid that completely, so no need to name contracts and no
> need for magic __invariant.


 For example,

 class Animal {
protected $legs;
require($legs >= 0);
 }

 class Snake extends Animal {
   // Snake is fine, no leg
 }

 class Human extends Animal {
   // 2 legs. $this->leg === 2
 }

 Overriding makes sense for many cases.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net

>>>
>>>
>>
>

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

completely agree. contracts must be permanent.

Thanks. Dmitry.

On Tue, Feb 10, 2015 at 10:40 AM, Joe Watkins  wrote:

> Example code never works, I can just say that's a bad abstraction,
> vertebrate and invertebrate are distinct and abstraction should reflect
> that.
>
> Why should we provide a way to change contracts is the question ?
>
> It doesn't seem to make sense to do that, a derived class should be able
> to define additional contracts, but not change the contracts of it's parent.
>
> Cheers
> Joe
>
> On Tue, Feb 10, 2015 at 7:36 AM, Yasuo Ohgaki  wrote:
>
>> Hi Joe,
>>
>> On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins 
>> wrote:
>>
>>> Actually I'm not sure it's at all sane to try to override contracts, I'd
>>> actually avoid that completely, so no need to name contracts and no need
>>> for magic __invariant.
>>
>>
>> For example,
>>
>> class Animal {
>>protected $legs;
>>require($legs >= 0);
>> }
>>
>> class Snake extends Animal {
>>   // Snake is fine, no leg
>> }
>>
>> class Human extends Animal {
>>   // 2 legs. $this->leg === 2
>> }
>>
>> Overriding makes sense for many cases.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>
>

Re: [PHP-DEV] Design by Contract

[Patrick Schaaf]

Am 10.02.2015 08:25 schrieb "Yasuo Ohgaki" :
>
>> 5) and a bit off-topic, it would be useful to be able to declare (sic)
whole methods to be nonproduction only: Methods that will only be used in
pre/post/invariant condition expresions (or error formatters a la my point
4)
>
> Do you mean enable DbC partially? Like
> declare(dbc=1);
> At the top of script?

Nono. i shouldn't have said declare, sorry.

What I meant is this (using a made-up keyword "dbconly" just for
exposition):

class foo {
   function normalmethod($arg)
   require($this->just_for_dbc_check($arg))
   {  }
   dbconly function just_for_dbc_check($arg) {
   ... whatever validation code ...
   return false;
   }
}

And then when DbC is inactive (production) metho just_for_dbc_check would
not be compiled at all / invisible.

I now realize that I'm asking for a way to have arbitrary PHP code for
checking, through a backdoor :)

But this _would_ permit some nice consolidation of more complex checks,
ones that maybe would be shared by several methods with repetition of the
expressions in the case we cannot do this.

Just thinking out loud, I fully agree with Dmitry's comment of keeping it
simple and manageable at the moment, and this is something that could be
added later at any time.

best regards
  Patrick

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

Example code never works, I can just say that's a bad abstraction,
vertebrate and invertebrate are distinct and abstraction should reflect
that.

Why should we provide a way to change contracts is the question ?

It doesn't seem to make sense to do that, a derived class should be able to
define additional contracts, but not change the contracts of it's parent.

Cheers
Joe

On Tue, Feb 10, 2015 at 7:36 AM, Yasuo Ohgaki  wrote:

> Hi Joe,
>
> On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins 
> wrote:
>
>> Actually I'm not sure it's at all sane to try to override contracts, I'd
>> actually avoid that completely, so no need to name contracts and no need
>> for magic __invariant.
>
>
> For example,
>
> class Animal {
>protected $legs;
>require($legs >= 0);
> }
>
> class Snake extends Animal {
>   // Snake is fine, no leg
> }
>
> class Human extends Animal {
>   // 2 legs. $this->leg === 2
> }
>
> Overriding makes sense for many cases.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Joe,

On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins  wrote:

> Actually I'm not sure it's at all sane to try to override contracts, I'd
> actually avoid that completely, so no need to name contracts and no need
> for magic __invariant.


For example,

class Animal {
   protected $legs;
   require($legs >= 0);
}

class Snake extends Animal {
  // Snake is fine, no leg
}

class Human extends Animal {
  // 2 legs. $this->leg === 2
}

Overriding makes sense for many cases.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Patrick Schaaf]

Am 10.02.2015 08:08 schrieb "Yasuo Ohgaki" :
>
> One reason I would like to use __invariant() is to allow overriding
parents.
> I think we should have way for it, but I don't have good idea now.
> I'm still thinking.

Hmm, Idea... Imagine the require keyword, in the context of classes, as an
alternative to the function keyword. One could write any of these:

class foo {
   require (expr); // like anonymous function. nonoverridable
   static require (expr); // same for nonmethod calls
   // _named_ form
   require something (expr);  // overrides
   static require otherthing (expr); // overrides
}

This way selective overriding would be possible for individual conditions.

The namespace for these invariant expression names could / should be wholly
separate from the method namespace itself.

best regards
  Patrick

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

Actually I'm not sure it's at all sane to try to override contracts, I'd
actually avoid that completely, so no need to name contracts and no need
for magic __invariant.

Cheers
Joe

On Tue, Feb 10, 2015 at 7:26 AM, Yasuo Ohgaki  wrote:

> Hi Dmitry,
>
> On Tue, Feb 10, 2015 at 4:21 PM, Dmitry Stogov  wrote:
>
> > 4) regarding the error message second argument to the condition
> >> definitions, it would be useful to have these not only as plain
> >> (extrapolated) strings, but as full expressions-that-evaluate-to-string.
> >> That would permit hooking to arbitrary private logging and log
> formatting
> >> methods.
> >>
> > I don't think we will implement this. It may be proposed later as a DbC
> > extension.
> >
>
> I thought it works just like assert(), but no problem for me.
>
>
> > 5) and a bit off-topic, it would be useful to be able to declare (sic)
> >> whole methods to be nonproduction only: Methods that will only be used
> in
> >> pre/post/invariant condition expresions (or error formatters a la my
> point
> >> 4)
> >>
> > this is also not directly related as well.
> > Sorry, but we should define realistic target to be able to provide a
> > working solution.
> > We can't think about all possible and indirectly related features at
> once.
> >
>
> I agree.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Dmitry,

On Tue, Feb 10, 2015 at 4:21 PM, Dmitry Stogov  wrote:

> 4) regarding the error message second argument to the condition
>> definitions, it would be useful to have these not only as plain
>> (extrapolated) strings, but as full expressions-that-evaluate-to-string.
>> That would permit hooking to arbitrary private logging and log formatting
>> methods.
>>
> I don't think we will implement this. It may be proposed later as a DbC
> extension.
>

I thought it works just like assert(), but no problem for me.


> 5) and a bit off-topic, it would be useful to be able to declare (sic)
>> whole methods to be nonproduction only: Methods that will only be used in
>> pre/post/invariant condition expresions (or error formatters a la my point
>> 4)
>>
> this is also not directly related as well.
> Sorry, but we should define realistic target to be able to provide a
> working solution.
> We can't think about all possible and indirectly related features at once.
>

I agree.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Joe Watkins]

> One reason I would like to use __invariant() is to allow overriding
parents.

Well, another approach would be optionally named contracts:

class Some {
require contractName (invariant-expr);
/* ... */
}

This would also improve default error messages as a by-product.

Cheers
Joe

On Tue, Feb 10, 2015 at 7:06 AM, Yasuo Ohgaki  wrote:

> Hi Joe,
>
> On Tue, Feb 10, 2015 at 3:59 PM, Joe Watkins 
> 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.
>>
>
> One reason I would like to use __invariant() is to allow overriding
> parents.
> I think we should have way for it, but I don't have good idea now.
> I'm still thinking.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Design by Contract

[Yasuo Ohgaki]

Hi Patrick,

On Tue, Feb 10, 2015 at 4:06 PM, Patrick Schaaf  wrote:

> Am 10.02.2015 07:25 schrieb "Yasuo Ohgaki" :
> >
> > https://wiki.php.net/rfc/dbc2
>
> First of all, thanks for your effort so far.
>
> Some questions, after reading the RFC, with no particular order:
>
> 1) Regarding invariants: those will be called for method calls on objects.
> What about static class methods? Could we have static class invariants
> (static require(.))? Would these be called for both static and
> nonstatic method calls (nonstatic method calls can change static class
> state, too)
>
Static calls should not use $this->var, so invariant condition is ignored.
It should be in the RFC.

> 2) the pre- and postconditions could be useful for ordinary, non-OO
> functions, too, to check parameters, return, and global state invariants
>
I proposed __invariant() function, but some would not like to have it.
Since you've requested, we may consider again.

Rre/postconditions (require/return) can be used for non-OO functions.
It should be in the RFC. I'll add it in the RFC later.

> 3) I think that method preconditions are not sufficient. Pretty often,
> public methods first sanitize and validate their input parameters, and
> rightly so. In these cases, it would be useful to have the checking, in the
> same general framework, at an arbitrary point in the function body. In
> other words, assert (with an expression as the first argument, instead of a
> string).
>
I might misunderstand you. Anyway,

assert( $var > 0 )

is allowed. So you can write usual PHP code. Even we can

assert( foo() ) // The same applies to require()/return()

is allowed. However, PHP does not allow in place closure call currently. We
cannot do

assert(function() { return $a > 0;} )

It's just ignored. This is the same as current assert().

> 4) regarding the error message second argument to the condition
> definitions, it would be useful to have these not only as plain
> (extrapolated) strings, but as full expressions-that-evaluate-to-string.
> That would permit hooking to arbitrary private logging and log formatting
> methods.
>
assert( $var > 0, '$var must be positive')

is allowed.
This should be in the RFC. require()/return() works just like assert().


> 5) and a bit off-topic, it would be useful to be able to declare (sic)
> whole methods to be nonproduction only: Methods that will only be used in
> pre/post/invariant condition expresions (or error formatters a la my point
> 4)
>

Do you mean enable DbC partially? Like

declare(dbc=1);

At the top of script?
I think it would not happen, but others may think it should.
Anyone?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Design by Contract

[Dmitry Stogov]

On Tue, Feb 10, 2015 at 10:06 AM, Patrick Schaaf  wrote:

> Am 10.02.2015 07:25 schrieb "Yasuo Ohgaki" :
> >
> > https://wiki.php.net/rfc/dbc2
>
> First of all, thanks for your effort so far.
>
> Some questions, after reading the RFC, with no particular order:
>
> 1) Regarding invariants: those will be called for method calls on objects.
> What about static class methods? Could we have static class invariants
> (static require(.))? Would these be called for both static and
> nonstatic method calls (nonstatic method calls can change static class
> state, too)
>
yeah, "static require()" may be a good addition. However, I don't like to
invite a bicycle, we are going to borrow most related semantic from D.

> 2) the pre- and postconditions could be useful for ordinary, non-OO
> functions, too, to check parameters, return, and global state invariants
>
any function will able to use contracts.

3) I think that method preconditions are not sufficient. Pretty often,
> public methods first sanitize and validate their input parameters, and
> rightly so. In these cases, it would be useful to have the checking, in the
> same general framework, at an arbitrary point in the function body. In
> other words, assert (with an expression as the first argument, instead of a
> string).
>
assert() will work as well. Actually, all these addition require/return
syntax is going to be just a syntax sugar that will finally call assert()s
in proper order.

> 4) regarding the error message second argument to the condition
> definitions, it would be useful to have these not only as plain
> (extrapolated) strings, but as full expressions-that-evaluate-to-string.
> That would permit hooking to arbitrary private logging and log formatting
> methods.
>
I don't think we will implement this. It may be proposed later as a DbC
extension.

> 5) and a bit off-topic, it would be useful to be able to declare (sic)
> whole methods to be nonproduction only: Methods that will only be used in
> pre/post/invariant condition expresions (or error formatters a la my point
> 4)
>
this is also not directly related as well.
Sorry, but we should define realistic target to be able to provide a
working solution.
We can't think about all possible and indirectly related features at once.

Thanks. Dmitry.



> best regards
>   Patrick
>