Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82774 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88421 invoked from network); 16 Feb 2015 05:56:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Feb 2015 05:56:51 -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.192.44 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.192.44 mail-qg0-f44.google.com Received: from [209.85.192.44] ([209.85.192.44:38943] helo=mail-qg0-f44.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 04/61-05176-1A681E45 for ; Mon, 16 Feb 2015 00:56:50 -0500 Received: by mail-qg0-f44.google.com with SMTP id j5so22016545qga.3 for ; Sun, 15 Feb 2015 21:56:47 -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=e45JQYgNMBt59F/109fcnH44J5tXdpjTj4VrjZznM5c=; b=c75InzjXY+e/q/+R4BfFeVtlxCt7j/8vsyiPtwmxpXc8esJZRz8UHGp90TohSBGGyC K+F8QZCSeXyInrmJckQnpmx/Abc8Veny4rrR5yn4j+Dpc4np2ctGTaEar+49sE2W6dxA oc9Tyiv1iqGcdvyZ5b0Z1NcxQ5eHFreNnFGzs1UDKENgGWlCvXGTNVYCVBViBK4AxHO+ T5o1V+XhcsTy7hWTKL3SMx1O879XF8pIeQ8R/Oa4ulMq9A045BG9dJl0NVutSLqrccg8 HLcbYduNQXGjak8PUgDA/eYPm4ZyRHhyjS+TtWtjeCi7jrFowrHawOvLg5TLS2bazMhV 9AhQ== X-Received: by 10.140.194.139 with SMTP id p133mr483154qha.21.1424066207326; Sun, 15 Feb 2015 21:56:47 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.198.8 with HTTP; Sun, 15 Feb 2015 21:56:07 -0800 (PST) In-Reply-To: <003d01d04974$46e52240$d4af66c0$@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> <003d01d04974$46e52240$d4af66c0$@php.net> Date: Mon, 16 Feb 2015 14:56:07 +0900 X-Google-Sender-Auth: 6ecd8kztYuv8ygdYpLvpiSW2Jsg Message-ID: To: francois Cc: Dmitry Stogov , Joe Watkins , Stanislav Malyshev , PHP Internals Content-Type: multipart/alternative; boundary=001a114284d66ca984050f2e403a Subject: Re: [PHP-DEV] Design by Contract From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a114284d66ca984050f2e403a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Francois, On Mon, Feb 16, 2015 at 8:08 AM, Fran=C3=A7ois Laupretre wrote: > > > De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo Ohgaki > > > > 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. > > That's true for pre-conditions, but that's not the way D handles post-conditions. > > >>> The same rule for class applies to interfaces. > >> > >> ?? I don't understand. > > > >Interface may have contracts just like class. > > OK, but when do you check interface conditions ? And how do you deal with interface (multiple) inheritance ? Simply check all contracts on method calls. If property check (invariant) could be issue, class designer should use document for proper property management rather than contracts. Or we may drop invariant support for interface. > > >>> 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? > > Sure, but are you realizing that you're discarding your own statement, not mine ? Type safety consideration was not intended at first. So I don't have problem with disregarding type safety. We may introduce type safety/system when we have template, strict types and/or overloading, for example. > I never told about the PHP type system because I don't understand what types have to do here. So, yes, I don't care about the PHP type system and that's not the subject. We are discussing about PHP conditions and when they are evaluated, that's all. > > And, sorry about that, but could you stop sending html messages ? It makes replies much harder. It seems gmail does not have the option, but I can only remove text formatting manually. Does this mail seems OK to you? Anyway, how about not to consider type safety too much now? and concentrate to introduce simple DbC? We may have option for strict type in the future for whatever type system we introduce at that time. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a114284d66ca984050f2e403a--