Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82707 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77197 invoked from network); 14 Feb 2015 23:18:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Feb 2015 23:18:27 -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.42 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.216.42 mail-qa0-f42.google.com Received: from [209.85.216.42] ([209.85.216.42:45191] helo=mail-qa0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6A/C1-00421-2C7DFD45 for ; Sat, 14 Feb 2015 18:18:27 -0500 Received: by mail-qa0-f42.google.com with SMTP id w8so17212277qac.1 for ; Sat, 14 Feb 2015 15:18:23 -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=YCvoh5t3SQ5eZAoewUp7w2vfLCYmm2v8P5gKoQiv6AE=; b=GWrYCvSZG21JDtbt4wROtJF1x8C1qDXJbAVS8x2ryJugnYi5LcoMe3jbZgG2jjxaY1 tb1r7YRtgnovQChir4VR9SjDXNkij0wbRbQyH4iHcCApt7w+d8VzgFdArFGPZCc9iw+L c5UXLk67+ILbzDzY7V9FbGDU7+x4NTVO5aIvpUqSM8xvIRdQUrWhvjJJlxC/iUk8x8ZH 9AWjL0WYpvFEFUjSEGF14WaXA4hRE2eKLLdWPv4dBAbg957aGleF1BmxoHv9yO3sXF31 E/4VW8Gf+0ZSSdgRsXEY/rpeSkYgbKsNDvBIjTVJAX3K7GoXtF+5NBpOLjwdvePGfP8s iw4g== X-Received: by 10.140.235.197 with SMTP id g188mr4292796qhc.86.1423955903409; Sat, 14 Feb 2015 15:18:23 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.198.8 with HTTP; Sat, 14 Feb 2015 15:17:43 -0800 (PST) In-Reply-To: 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 08:17:43 +0900 X-Google-Sender-Auth: yeo1brCMjHrN-zMBfnsNlD5PwOA Message-ID: To: Robert Stoll Cc: francois , Dmitry Stogov , Joe Watkins , Stanislav Malyshev , PHP Internals Content-Type: multipart/alternative; boundary=001a11357acecc76d7050f1491b2 Subject: Re: [PHP-DEV] Design by Contract From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a11357acecc76d7050f1491b2 Content-Type: text/plain; charset=UTF-8 Hi all, On Sun, Feb 15, 2015 at 7:53 AM, Yasuo Ohgaki wrote: > 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?? > I wrote simple D program "sample.d" to play with. Install D, then dmd sample.d && ./sample ====sample.d==== import std.stdio; class A { int x = 1; int y = 2; public: void set (int x, int y) in { assert(x > 0); assert(y > 0); } body { this.x = x; this.y = y; } int mul() out (ret) { assert(ret > 0); } body { return x * y; } invariant { assert(this.x > 0); assert(this.y > 0); } } class B : A { int a; int b; override void set (int a, int b) in { assert(a > 4); assert(b > 2); } body { this.a = a; this.b = b; } override int mul() out (ret) { assert(ret > 4); } body { return a * b; } invariant { assert(this.x > 0); assert(this.y > 0); } } class C : A { override void set (int x, int y) in { // Cannot work with override assert(x > -4); assert(y > -2); } body { this.x = x; this.y = y; } override int mul() out (ret) { assert(ret > -4); } body { return x * y; } // This cannot work. Less restrictive than parent invariant { assert(this.x > -4); assert(this.y > -2); } } void main() { A a = new A; B b = new B; C c = new C; a.set(4,2); writeln("Ans: ", a.mul()); // -1 is invalid //a.set(-1, 0); core.exception.AssertError@sample.d(10): Assertion failure b.set(5,3); // Fine with B. B is different type. writeln("Ans: ", b.mul()); } ================= As you can see, D has type safety by contracts and does non-intuitive checks. Question is "Does PHP need this kind of type safety?" I totally agree strict type safety is good for writing correct programs, BTW. D has type safety feature since it has strong type. If PHP is going to be strongly typed language as scalar type hint RFC, and might be stronger type than now. We may consider stricter types later. It's not just time for it. IMHO. PHP may be extended to check contracts like D when declare('strict_types'=1). Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a11357acecc76d7050f1491b2--