Hi Yasuo > -----Ursprüngliche Nachricht----- > Von: yohg...@gmail.com [mailto:yohg...@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 <p...@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 > yohg...@ohgaki.net[Robert Stoll] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
