Hi François
> -----Ursprüngliche Nachricht-----
> Von: François Laupretre [mailto:franc...@php.net]
> Gesendet: Sonntag, 15. Februar 2015 11:43
> An: 'Robert Stoll'; 'Yasuo Ohgaki'
> Cc: 'Dmitry Stogov'; 'Joe Watkins'; 'Stanislav Malyshev'; 'PHP Internals'
> Betreff: RE: [PHP-DEV] Design by Contract
>
> > 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
Unfortunately, I am not familiar with Eiffel or D, so I am just assuming and
cannot really give you the specific reason behind the design decision.
Having LSP-safe contracts allow that a type checker has do perform a conformity
check only once and not for each case which is most probably way to slow and
further cannot guarantee contract-safety at compile-time anyway (Eiffel and D
are both statically typed).
Considering my example again, this time with some kind of static typing:
class A{
function foo(int $x){
pre($x > 100);
}
}
class B extends A{
function foo(int $x){
pre($x > 50); // less restrictive, that's fine
}
}
class C{
function foo(int $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
A $a = new C(); //the type checker thinks $a is of type A, does not know that
it has actually type C
foo($a); //not possible for a type checker to see the violation
With the LSP rule in place the type checker does not need to verify the
function call foo since everything of type A will conform anyway.
Makes sense no? But as I said, I am just assuming. Someone familiar with Eiffel
or D can probably give some insights.
I totally agree with you that such a check is not feasible for PHP, a
dynamically typed language in general respectively.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
