AW: [PHP-DEV] Design by Contract
| From: | Robert Stoll | Date: | Sat, 14 Feb 2015 23:14:24 +0000 |
| Subject: | AW: [PHP-DEV] Design by Contract | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-82706@lists.php.net to get a copy of this message | ||
Hi Yasuo
> -----Ursprüngliche Nachricht-----
> Von: yohgaki@gmail.com [mailto:yohgaki@gmail.com] Im Auftrag von Yasuo Ohgaki
> Gesendet: Samstag, 14. Februar 2015 23:54
> An: Robert Stoll
> Cc: francois; Dmitry Stogov; Joe Watkins; Stanislav Malyshev; PHP Internals
> Betreff: Re: [PHP-DEV] Design by Contract
>
> 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 <php@tutteli.ch> 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.
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 am not sure how easy it would be or rather how much performance impact it would have when we try
to enforce LSP for DbC. I think it is not feasible for PHP.
So I would say we leave it up to the user and he/she has to make sure that LSP is not violated. A
static analyser could still help the user and point out LSP violations, I think that does not need
to be part of the language.
>
> Regards,
>
> P.S. Are we really going to consider strict type safety for PHP??
If you mean strong typing for PHP then no, certainly not.
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net[Robert Stoll]