Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82751 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11949 invoked from network); 15 Feb 2015 21:35:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Feb 2015 21:35:44 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.47 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.216.47 mail-qa0-f47.google.com Received: from [209.85.216.47] ([209.85.216.47:52723] helo=mail-qa0-f47.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 46/91-02981-E2111E45 for ; Sun, 15 Feb 2015 16:35:42 -0500 Received: by mail-qa0-f47.google.com with SMTP id v10so19815893qac.6 for ; Sun, 15 Feb 2015 13:35:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=7reSoPZpr0hALnG90NKI3CRUUlv4CFGB6wXkJWN4DEY=; b=ZGIcBa8IGeaiYP8PBjcQM+HNCopLnuu7Zo6Pog8koikQhYyGHchvcFPRWvwsZw9W7Y zxqL9yxpAPZMmCEj8xb4D6hFDbTfrVhvmlOgCGrzulDARpTc/aR9RAycOxWLV4eivBqJ 2oRVz0PrK8b4NEcoM4TA3NfCoitFX9QVysbyEhUFj5slFgqUA82SHpA12MD+sZQ8FOg0 ZGLTdkCAG7DGXo5UaWX+M9wLek/Ek7IVssW68dSKIqerWfht6oj2ONNRAxv5wnYk2oWf QycsGekxM7/SBTFQVjqP/srLCwik0YXYsqUGpahH9zeLkeMYBJFJin1gMk/XOTVcw7rM eaDA== X-Received: by 10.140.109.164 with SMTP id l33mr367637qgf.91.1424036139607; Sun, 15 Feb 2015 13:35:39 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.198.8 with HTTP; Sun, 15 Feb 2015 13:34:59 -0800 (PST) In-Reply-To: <000a01d04939$aae34910$00a9db30$@php.net> References: <54DAFD32.3000005@gmail.com> <54DB0BC0.20304@gmail.com> <54DBA801.8060403@gmail.com> <013801d0481d$d34c5170$79e4f450$@php.net> <000a01d04939$aae34910$00a9db30$@php.net> Date: Mon, 16 Feb 2015 06:34:59 +0900 X-Google-Sender-Auth: 9H4YJOuvg9qiwa-4aO5yZaYcL6Q Message-ID: To: francois Cc: Dmitry Stogov , Joe Watkins , Stanislav Malyshev , PHP Internals Content-Type: multipart/alternative; boundary=001a113a304e3fb358050f274008 Subject: Re: [PHP-DEV] Design by Contract From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a113a304e3fb358050f274008 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Francois, On Mon, Feb 16, 2015 at 1:08 AM, Fran=C3=A7ois 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_scienc= e) 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 w= e > > 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 yohgaki@ohgaki.net --001a113a304e3fb358050f274008--