Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82186 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73080 invoked from network); 8 Feb 2015 22:57:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Feb 2015 22:57:58 -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.180 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.216.180 mail-qc0-f180.google.com Received: from [209.85.216.180] ([209.85.216.180:52575] helo=mail-qc0-f180.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B7/09-26926-4F9E7D45 for ; Sun, 08 Feb 2015 17:57:57 -0500 Received: by mail-qc0-f180.google.com with SMTP id s11so198172qcv.11 for ; Sun, 08 Feb 2015 14:57:54 -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=xmqYULjXITKXVw9ztQ+VD6c/C5EaagBtiYyfYGdg1iA=; b=DcBue6Lo8wMIjCzzAXVD2jW8knTyGKhK8YL7IwFFo39RM2JCvz+96mj2qWkHXDqLoq eXLIjOnnJH7DRzOqGdRrCfpAotbUL2p14yNCHbdnL2NhRdLfCQkFnOdTsgpu0wXZEugw 1sSpPnGFYu/wbesTr0A0+2YojWj82VssJhFqpp96/58pRjQ+aQLww2c0/u3vIx0s22JV Sz5yjiFyAKKFb3Iss6IQlYtnliK7HxhL03980gEwp7QDQu9YOw2p9NVw6QTt+nve3YNN NQDAZSTQpd+CCTBHCvFLR+u3OmO0GvCQEFV5IQslIWb0DVdl+kUcQdNj0RT/SvV8/If9 wMtA== X-Received: by 10.140.21.229 with SMTP id 92mr32974209qgl.33.1423436273912; Sun, 08 Feb 2015 14:57:53 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.28.72 with HTTP; Sun, 8 Feb 2015 14:57:13 -0800 (PST) In-Reply-To: <03f301d043b6$0e79b330$2b6d1990$@tekwire.net> References: <03f301d043b6$0e79b330$2b6d1990$@tekwire.net> Date: Mon, 9 Feb 2015 07:57:13 +0900 X-Google-Sender-Auth: LGiEE7_i0wy3VewRqMtX9gu2Zgk Message-ID: To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= , Dmitry Stogov Cc: guilhermeblanco , PHP Internals Content-Type: multipart/alternative; boundary=001a11c12f8c779393050e9b95c1 Subject: Re: Design by Contract From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a11c12f8c779393050e9b95c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Francois, On Mon, Feb 9, 2015 at 12:43 AM, Fran=C3=A7ois Laupretre wrote: > > De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo > Ohgaki > > > > Since people's preferences are diverse. It might be a good idea having > pre-vote > > for designs, then we may have final vote with single design. > > > > We need some consensuses even for pre-vote. > > > > What do you think? > > What I think is that I have written a 600-line RFC, that you refuse to > comment because you still hope you can impose a D-like syntax by another > way. I don't agree on a pre-vote on design and, then, care about details, > because that's just an artefact to get an agreement on D-like syntax befo= re > people can read and understand my proposal, and without exploring the > implications of your design. > > Here is a fair way to proceed: I have written an RFC, trying to explore > honestly every aspects of the design I'm proposing. Now, either you agree= , > or you write yours with the same goal in mind. Then, we may choose. That'= s > the rule. Saying 'I don't like that' without proposing an alternative is > not the right way. I won't help you get an a-priori approval, just to say > thereafter that, whatever problem we find, we must stick with this design > because it was pre-approved. If you write an RFC and people approve it, > that's OK. > > Anyway, as I think DbC can be implemented without any change in the core, > I'll probably implement it by myself as a zend extension. So, you can do > what you want in PHP 7. I agree. I can also implement basic DbC feature as zend extension. It will be ugly without parser modification, but the change wouldn't be too hard. I'm sure Dmitry would do much better job than me :) You would like me to write D like version. No problem at all. If majority/consensus is annotation approach, I don't insist to have D like proposal. If you would like to choose by vote anyway, I'll write/add RFC with Dmitry's idea in mind. Dmitry, what is your opinion now? It's not mandatory, but I still prefer to have D like syntax because users can code contracts just like PHP code and get all kinds of syntax errors/et= c as PHP. Would you like to have D like syntax as vote option or choose with one of annotation/D like before vote? (It seems annotation is more popular) D like design has advantage that internal functions/classes may have contracts just like user space. This may help to get better performance also. User would get consistent/similar contract errors from internal classes/functions. (I can imagine number of people against raising E_WARNING from classes, though) Guiherme, you have comprehensive annotation implementation. Could you give us your idea's about DbC and annotation? Is your idea the same as Francois's? https://wiki.php.net/rfc/dbc We don't have much time. I hope we have consensus before deadline. Thank you. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a11c12f8c779393050e9b95c1--