Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82705 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73660 invoked from network); 14 Feb 2015 22:54:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Feb 2015 22:54:40 -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.50 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.216.50 mail-qa0-f50.google.com Received: from [209.85.216.50] ([209.85.216.50:55600] helo=mail-qa0-f50.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8D/11-00421-E22DFD45 for ; Sat, 14 Feb 2015 17:54:40 -0500 Received: by mail-qa0-f50.google.com with SMTP id f12so17502370qad.9 for ; Sat, 14 Feb 2015 14:54:36 -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=jyQtqqcZuIYTorRMXjXx0RNx6vR4/sLlahW/T2xCyJ0=; b=fQjyJmQ40IR5hWGtYkwfxbAl80CxXcei/UG6NlxnQ6jkA9QElpHn2TtNVJuAbyiZzl Wp9alzWXrHek3jFIdfKf6NefZNT1gmrOlqFLWehrVZvqlHDAE1Otf+7A/6BGsujX5dgR cbk+l2jBj2gDj+9nqS9CYexZRuKOHebaTKNKN4wGi+c+XJGF5HVpyWEn7KoVZtkIYrah nRYeJUs2kQKyaw9q8s3r1xWgyElYutCaklOvMQNWvjgwsptxZQF1gHJ4I/s83FZ+PSQ0 g1IM3BA2JK6LceaK7zTusXXQOfEOZtHa1FmQlymtTp4J/OtKLfg4bNqVG5t8CuSScWCB b0iw== X-Received: by 10.140.151.13 with SMTP id 13mr11936789qhx.68.1423954475932; Sat, 14 Feb 2015 14:54:35 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.198.8 with HTTP; Sat, 14 Feb 2015 14:53:55 -0800 (PST) In-Reply-To: <002701d04846$50c0d630$f2428290$@tutteli.ch> References: <54DAFD32.3000005@gmail.com> <54DB0BC0.20304@gmail.com> <54DBA801.8060403@gmail.com> <011e01d04802$cbd78ce0$6386a6a0$@php.net> <013801d0481d$d34c5170$79e4f450$@php.net> <002701d04846$50c0d630$f2428290$@tutteli.ch> Date: Sun, 15 Feb 2015 07:53:55 +0900 X-Google-Sender-Auth: Sq1cFISf4YBz8g3rBqVuTlCF38U Message-ID: To: Robert Stoll Cc: francois , Dmitry Stogov , Joe Watkins , Stanislav Malyshev , PHP Internals Content-Type: multipart/alternative; boundary=001a113553f2b6e1f7050f143c52 Subject: Re: [PHP-DEV] Design by Contract From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a113553f2b6e1f7050f143c52 Content-Type: text/plain; charset=UTF-8 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 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. Regards, P.S. Are we really going to consider strict type safety for PHP?? -- Yasuo Ohgaki yohgaki@ohgaki.net --001a113553f2b6e1f7050f143c52--