Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58711 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16047 invoked from network); 7 Mar 2012 02:04:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Mar 2012 02:04:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=johncrenshaw@priacta.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=johncrenshaw@priacta.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.241 as permitted sender) X-PHP-List-Original-Sender: johncrenshaw@priacta.com X-Host-Fingerprint: 64.95.72.241 mxout.myoutlookonline.com Received: from [64.95.72.241] ([64.95.72.241:13468] helo=mxout.myoutlookonline.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4D/B6-15021-B12C65F4 for ; Tue, 06 Mar 2012 21:04:12 -0500 Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 458C07E6454; Tue, 6 Mar 2012 21:04:09 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id AF0507E63C5; Tue, 6 Mar 2012 21:04:08 -0500 (EST) Received: from MAILR001.mail.lan ([10.110.18.27]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Tue, 6 Mar 2012 21:03:48 -0500 To: Anthony Ferrara CC: Simon Schick , Kris Craig , Raymond Irving , "internals@lists.php.net" Date: Tue, 6 Mar 2012 21:04:01 -0500 Thread-Topic: [PHP-DEV] Scalar Type Hinting Thread-Index: Acz79aESvU18Y++6TkGZlIJ4YHR99wACqi9Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [PHP-DEV] Scalar Type Hinting From: johncrenshaw@priacta.com (John Crenshaw) Disclaimer: The following is direct (maybe brutally so). I'm not trying to = hurt any feeling or attack, but I'm not pulling punches either. I don't hav= e the energy right now to polish this and make it all nice and gentle, so I= 'm sorry in advance. I hope you'll look past the directness and be able to = get some useful feedback. > John, > > > Sorry, I disagree. This is nowhere close IMO, and silence doesn't denot= e consent in this case. I actually basically stopped participating when it = became apparent that people were determined to rush head first into creatin= g a doomed RFC without any process to ensure that historical arguments were= considered and addressed, with minimal attention to feedback, and with no = concern for syntax (proposed syntax is as bad as the namespace syntax). > > Well, my take on it was that thinking out-loud in a thread is not going t= o get us anywhere with nothing to base the conversation on. So I picked an= option and proposed it. As now, we can base the conversation around a rea= l implementation. Don't like the syntax? > Great! Let's find a better solution. But I felt that it was more import= ant to put a base for the conversation, rather than just letting it wander = aimlessly. > Yes, it was aimless discussion (though some would call it brainstorming). I= t was ready to move to the next level, which should have been gathering the= constraints/requirements/problems into a coherent list to work from. What = happened though was that this step was skipped entirely, so now there's bee= n an attempt to write a preliminary spec without gathering the requirements= first, which IMO is far worse than any amount of aimless discussion. > > I'm in favor of addressing the type hinting issue, but I'm opposed to t= his RFC. It is crippled, confusing, and has a plethora of unaddressed issue= s. > > Then point out the issues. Help improve it and make it something that *should* go in the core. That's why it's still in draft mode. I didn't pr= opose it, or put it for discussion, I put it in draft for that very reason. > A good number of issues with the current proposal were raised during the di= scussion on the mailing list. I don't feel like digging them all up right n= ow, but off the top of my head I remember the following being raised and ne= ver saw any consensus for how to resolve them: - inconsistent syntax (one syntax for scalars, a different one for classes) - conflicting syntax (I.E. array vs. (array), RFC simply "allows" this, and= ignores the confusion that this will create for users.) - different from the syntax used in the docs - lack of sufficient function to justify a core change - chaos surrounding null (to accept and if so to cast or not? Creates a con= flict between consistency and implications of the syntax) - conflicts with references (RFC tries to address this by simply disallowin= g references, which IMO just ignores the need that would have caused this s= ort of code in the first place.) There were others, but I'm not making an exhaustive list. > As far as it being crippled, I'm not sure what you mean, just because it'= s only doing casting? > Yes, casting is barely better than doing nothing. If I want a dumb typecast= I can do that already. What I can't do without massive boilerplate everywh= ere is an intelligent conversion that accepts safe conversions and gives a = warning or error on unsafe conversions. > As far as confusing, it is? I thought this was actually one of the more = straight forward proposals, since it re-used so much from the core (meaning= that it doesn't add new behavior, it re-uses existing behavior). > Yes, the syntax has some critical issues that create conflicting expectatio= ns. Look at the prior discussion. The current proposal doesn't really fix m= ost of this. > As far as having a plethora of unadressed issues, I'm absolutely sure it = does. But I haven't seen a single one put out there so that it can be fixe= d... > Again, look at the prior discussion of this syntax. Plenty of issues raised= . > > The object cast has similar problems, and although I recognize the valu= e of this sort of functionality, the current proposal seems to mostly ignor= e a number of critical problems that were raised when it was discussed on t= he mailing list. > > Which were? The critical problems that I saw on the list were mostly rel= ated to the original proposal wrapping set() with __assign() (which this pr= oposal removed). The only known issues that I know of that remains is with= the __toScalar() part (which in worst case can be removed from the proposa= l). > The biggest one that comes to mind is behavior with respect to operators. _= _toScalar() in your spec is an attempt to handle this, but IMO it really do= esn't cut it. Off the top of my head problems with this solution include: - This will lead to duplicated code - Thinking about my own code, I have almost no idea how I would actually wr= ite a robust __toScalar() implementation. It's still going to be returning = a string, or an integer. Very confusing. > > > These are RFCs. I am (as their author) explicitly asking for your commen= ts and contribution. They are not set in stone in the least... > In fact, the only way they would get to the point where I would propose t= hem is with enough input and overview that it was mature. They are not mature now. > > Can we make them mature? > > Thanks, > > Anthony Well, the big issue for me is that I think the type casting hints starts fr= om a fundamentally bad foundation. The premise here is based on a syntax th= at is ugly and strange, and the syntax opens a bunch of new problems that I= don't see a way to resolve. The reason for selecting this syntax was to av= oid a BC break from reserving some new keywords. I don't really see this as= a good trade. As for the automatic casting functions, I like the concept, but some seriou= s problems were raised in the discussions and many were never resolved very= well. To some extent I'm not really seeing good solutions either. If I thi= nk of a solution I'll be sure to mention it, but right now this looks very = much like a dead end to me. John Crenshaw Priacta, Inc.