Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83826 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44625 invoked from network); 25 Feb 2015 21:32:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Feb 2015 21:32:46 -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.46 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.192.46 mail-qg0-f46.google.com Received: from [209.85.192.46] ([209.85.192.46:52149] helo=mail-qg0-f46.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4E/E1-34010-D7F3EE45 for ; Wed, 25 Feb 2015 16:32:45 -0500 Received: by mail-qg0-f46.google.com with SMTP id z107so5409204qgd.5 for ; Wed, 25 Feb 2015 13:32:42 -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=gLsC1wHM49iUCvXvze+5dVEX89AZ1jbn4cB2Lcc+S50=; b=Szl97qW/cUT/F+JAyu8EPPbuJq2SvAkwsIkAGGdArVMxJzv/rNmsxXvpGT6xNpQ+ZM 6mpu0lYTZ4i9D1o4pTh2sgHi8H9qGHlovdeedF6/eZdJuHvxpSrYxYWJru99aQuwUG1Y Br+aeJsTO8VicJ8+wIFa7OTn2heLaoEERu3Zt/huh0pN9+cAhof+R9p3BRPqVEtaiIMT mEd6lGNIAaV2G/n07tHl35QOrJCFnfKYc+JOX+Mn1+zGsDzoMVDGWI3FtWEuN+Gn68e9 r6CZ3pDLcav4j9c4JVnQykTk731VG8umZkctvCOLbkwXeXkmYzZuNhwrgPdz8sVqUcQf 7rBw== X-Received: by 10.140.238.79 with SMTP id j76mr11411204qhc.83.1424899962025; Wed, 25 Feb 2015 13:32:42 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.198.8 with HTTP; Wed, 25 Feb 2015 13:32:01 -0800 (PST) In-Reply-To: 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: Thu, 26 Feb 2015 06:32:01 +0900 X-Google-Sender-Auth: Y03l1XSACXtLKoR19csUaDXsZIo Message-ID: To: francois Cc: Dmitry Stogov , Joe Watkins , Stanislav Malyshev , PHP Internals Content-Type: multipart/alternative; boundary=001a1135cda213bc25050ff06069 Subject: Re: [PHP-DEV] Design by Contract From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a1135cda213bc25050ff06069 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I would like to start [DISCUSSION] for this RFC. RFC may needs update, but these changes can be done during the discussion also. Any comments for staring discussion? P.S. I'll prepare simple "Vote Only" RFC for 2 RFCs. Please feel free to change/improve it. -- Yasuo Ohgaki yohgaki@ohgaki.net On Mon, Feb 16, 2015 at 2:56 PM, Yasuo Ohgaki wrote: > 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 ignore= s > 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 pare= nt > > >>> 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 an= d > 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 > > --001a1135cda213bc25050ff06069--