Hi Francois, On Mon, Feb 16, 2015 at 1:08 AM, François Laupretre <franc...@php.net> 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# Invariant Invariant 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
