Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58359 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3430 invoked from network); 29 Feb 2012 22:27:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 22:27:13 -0000 Authentication-Results: pb1.pair.com header.from=zeev@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=zeev@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.199.177.89 as permitted sender) X-PHP-List-Original-Sender: zeev@zend.com X-Host-Fingerprint: 212.199.177.89 il-mr1.zend.com Received: from [212.199.177.89] ([212.199.177.89:45196] helo=il-mr1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 14/BB-46815-E36AE4F4 for ; Wed, 29 Feb 2012 17:27:12 -0500 Received: from il-gw1.zend.com (unknown [10.1.1.22]) by il-mr1.zend.com (Postfix) with ESMTP id 7F9A960783; Thu, 1 Mar 2012 00:25:30 +0200 (IST) Received: from IL-EX2.zend.net ([fe80::6d27:be2c:57f3:272a]) by il-ex2.zend.net ([fe80::6d27:be2c:57f3:272a%14]) with mapi id 14.01.0255.000; Thu, 1 Mar 2012 00:26:34 +0200 To: Kris Craig CC: John Crenshaw , Richard Lynch , "internals@lists.php.net" Thread-Topic: [PHP-DEV] Scalar type hinting Thread-Index: AQHM9Pd1Qp/0dOE4ZEqZmcttXqmL3pZP+wSAgACx+ICAABNzAIAACoQAgAAKyoCAAAvyAIAAFSYAgAAGCQCAAAcOgIAAL6sAgAAAxACAAYR9gIAAAJIAgAABqwCAAAGjgIABTBtAgAA65wCAACb30P//6S0AgAAiHuA= Date: Wed, 29 Feb 2012 22:26:33 +0000 Message-ID: <887FE7CFF6F8DE4BB3A9535F53AFD06AC31532CB@il-ex2.zend.net> References: <1330357150.2159.30.camel@guybrush> <693e15008681dfe7372eaea66214f8a8.squirrel@www.l-i-e.com> <887FE7CFF6F8DE4BB3A9535F53AFD06AC3152C6C@il-ex2.zend.net> <887FE7CFF6F8DE4BB3A9535F53AFD06AC3152F5D@il-ex2.zend.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.199.177.84] Content-Type: multipart/alternative; boundary="_000_887FE7CFF6F8DE4BB3A9535F53AFD06AC31532CBilex2zendnet_" MIME-Version: 1.0 Subject: RE: [PHP-DEV] Scalar type hinting From: zeev@zend.com (Zeev Suraski) --_000_887FE7CFF6F8DE4BB3A9535F53AFD06AC31532CBilex2zendnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kris, Responses aren't inline. I'll go back to the mode that most other core dev= s are employing right now and ignore it for the waste of time that it is. = I won't ignore it if it ever comes to a vote, nor will the others. Troll away. Zeev From: Kris Craig [mailto:kris.craig@gmail.com] Sent: Thursday, March 01, 2012 12:16 AM To: Zeev Suraski Cc: John Crenshaw; Richard Lynch; internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting Responses inline. --Kris On Wed, Feb 29, 2012 at 1:49 PM, Zeev Suraski > wrote: Kris, If we've agreed that strict typing is bad, why is it even showing on the di= scussion here? Calling it 'firm' or 'strong' doesn't make a difference. I= f it errors out or throws an exception (which BTW is out of the question fo= r a language feature), it's strict typing, regardless of naming. That is a form of cognitive dissonance, a logical fallacy. More colloquial= ly known as an "either or argument." Everyone agrees that strict C-like typing is not tenable. We've moved past= that and what's being proposed now does not rise to that level. Thanks for pointing me to the voting procedure that I helped author. You're welcome. Are you essentially telling us we all have to waste our time again just bec= ause 6 months have passed? Yes. Though given how many people have shown an interest in this thread, I= would challenge your assertion that it is a waste of time. If you feel as= though it's a waste of your time, then don't waste your time. But that do= esn't give you the right to demand that we cease talking about it just beca= use you don't think it's a worthy discussion. That alone might be reason enough to turn the OR in there into an AND and= shut down that loophole. You're free to introduce a new RFC for that, but don't be surprised when I = and probably a number of others campaign heavily and tirelessly against it.= I don't think most people would agree with such a totalitarian approach d= esigned to silence dissenting views from being introduced and discussed. The rationale behind that time period was to allow for cases where there = was an 'almost' majority. Here, the proposal stands no chance. The only r= eason you're not seeing anybody from the core devs responding is because th= ey're tired of the Nth incarnation of the same discussion happening again w= ith zero new ideas. Please refer to the Wikipedia link I posted above pertaining to "weasel wor= ds." Just because a conceptually similar proposal failed two years ago doesn't m= ean the discussion we're having now won't have any support. If you can show why it makes sense to revive the discussion based on the 2n= d bullet, that is: The author(s) make substantial changes to the proposal. While it's impossib= le to put clear definitions on what constitutes 'substantial' changes, they= should be material enough so that they'll significantly effect the outcome= of another vote. ... then it's worth discussing. Nothing I saw in this thread falls under t= hat category, as far as I can tell. I disagree. A number of ideas have been put forth that differ from previou= s proposals. Just because you don't think they differ enough does not mean= you can unilaterally declare that this discussion must end. Besides, as y= ou said, such a standard would be completely arbitrary and open to interpre= tation. It would ultimately be something that would have to come down to a= vote (unless you're planning on being the one who gets to decide for the r= est of us what's substantial and what's not), which would render the whole = argument pointless anyway, since it would essentially be a vote on whether = or not we should have a vote. That's how the United States Congress typica= lly operates, and we all know how effective they are.... Let's put it to rest. This issue isn't going away. Again, we've already addressed this in previo= us posts. You may not want to discuss it, and there may be people who shar= e your sentiment, but that does not give you the authority to shut down thi= s conversation or declare that you're going to change the RFC rules so that= we can't vote on this. If that's not what you were proposing, then please= accept my apologies for the misunderstanding. Either way, I've already pr= omised to push back hard against any efforts to silence the discussion this= time around, and I intend to honor that promise. I am still in favor of ultimately moving this conversation to a separate lo= cation if people like Zeev are just tired of having this in their inboxes. = Plus it would give those of us who are actually interested in this a place= to brainstorm without old fear tactics periodically being reintroduced in = an effort to derail the conversation. I'll investigate such options as soo= n as I have some spare moments. It's been a busy week. =3D) Zeev From: Kris Craig [mailto:kris.craig@gmail.com] Sent: Wednesday, February 29, 2012 11:18 PM To: Zeev Suraski Cc: John Crenshaw; Richard Lynch; internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting ....Aaaaaand here we go again. Every few days it seems, somebody jumps int= o this thread and reminds us that strict typing is a bad idea, despite the = fact that we've already all agreed on that point about a gazillion times. As for past RFC's, I would recommend you review the voting procedure. If a= n RFC is rejected, the policy does allow it to be re-introduced after 6 mon= ths. While we're not actually reviving a previously rejected RFC since we'= re discussing a different approach, even if you were to apply that to the b= roader conceptual level, this discussion is still perfectly kosher since, a= s you said, that rejection happened 1.5 years ago (3 times the required per= iod). Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed a= t this repetitive pattern by now. We start finding common ground and makin= g progress, then somebody new makes a post about the evils of strict typing= and questioning why we're talking about this, obviously completely ignorin= g the fact that we've already addressed this numerous times. So Zeev, whil= e I appreciate your interest and welcome you to participate, please take an= other look at the previous posts in this thread, because we have already ad= dressed your concerns ad nauseum and have since moved-on. I do not want us= to get dragged back into grinding our wheels in the mud on that. Thank yo= u for your understanding. --Kris On Wed, Feb 29, 2012 at 1:09 PM, Zeev Suraski > wrote: Guys, I've followed this thread silently so far, and I'm wondering what changed o= ver the last ~1.5years that warrants a new discussion into that matter. I think the previous discussion ended with a pretty clear directive that st= rict typing has no place in PHP. Rasmus said about the proposal back then = "They aren't hints. It is strict typing and in its current form I would as= k you guys not to call the 5.4 release PHP." - which put in one sentence wh= at several others (myself included) put in many more words. So the 'strong= '/'firm'/'strict'/whatnot version of what is being discussed here, should p= robably not be discussed at all. We've been through it, and rejected it. Back when we rejected strict typing, we also 'killed' the other RFC[*] that= was born out of that old discussion - the 'weak' auto-conversion RFC. If = I recall correctly, it was for two reasons - one was that the proponents of= the strict typing said they'll firmly object weak typing, and the other is= that this RFC still had some issues that didn't seem obvious to hammer out= (main one I recall is that sticking to PHP's standard type juggling rules = meant that feature wasn't very useful, and we didn't feel very comfortable = introducing brand new type juggling rules just for that feature). If you w= ant to revive that discussion, I suggest you take a look at that RFC - conf= ine yourselves to only work on stuff that stands a chance to get accepted (= no strict typing) - and try to come up with good answers to the open questi= ons. No point in redoing the whole discussion from scratch. Zeev [*]https://wiki.php.net/rfc/typecheckingstrictandweak > -----Original Message----- > From: Kris Craig [mailto:kris.craig@gmail.com] > Sent: Tuesday, February 28, 2012 11:58 PM > To: John Crenshaw > Cc: Richard Lynch; internals@lists.php.net > Subject: Re: [PHP-DEV] Scalar type hinting > > Err sorry yes John is correct. I wasn't paying close enough attention. > > Here's *my* vision of how that progression would look: > > $a =3D "1"; // Current kosher unchanged. > weak int $a =3D "1"; // Converts to 1. No error thrown. > strong int $a =3D "1"; // Converts to 1. May or may not throw an error (= I'm still on > the fence). > > $a =3D "blah"; // Current kosher unchanged. > weak int $a =3D "blah"; // Throws E_x error level. > strong int $a =3D "blah"; // Throws E_y error level. > > > Where E_y > E_x. > > --Kris > > > On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw > >wrote: > > > No, In the example given there's an error on int $a =3D "1". There > > should be no error because this juggles fine. > > > > John Crenshaw > > Priacta, inc. > > > > -----Original Message----- > > From: Kris Craig [mailto:kris.craig@gmail.com] > > Sent: Tuesday, February 28, 2012 4:47 PM > > To: Richard Lynch > > Cc: internals@lists.php.net > > Subject: Re: [PHP-DEV] Scalar type hinting > > > > @Richard That's fairly close to what I'm thinking, yes. But there > > seems to be a diverse range of ideas bouncing around right now, so at > > present it's all in flux. > > > > --Kris > > > > > > On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch > wrote: > > > > > On Mon, February 27, 2012 4:34 pm, Kris Craig wrote: > > > > I think this is the main reason for differentiating between "strong= " > > > > (or > > > > whatever word is appropriate) and "weak." The developer may very > > > > well want their script to blow-up in such a case. > > > > > > I believe I actually "get it" now... > > > > > > You want 3 layers: > > > > > > $a =3D "1"; //current kosher unchanged weak int $a =3D "1"; // some E= _x > > > error level strong int $a =3D "1"; // some E_y error level where E_y = > > > > E_x > > > > > > Is that a correct summation? > > > > > > -- > > > brain cancer update: > > > http://richardlynch.blogspot.com/search/label/brain%20tumor > > > Donate: > > > > > > https://www.paypal.com/cgi-bin/webscr?cmd=3D_s-xclick&hosted_button_i= d > > > =3DF > > > S9NLTNEEKWBE > > > > > > > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > > > visit: http://www.php.net/unsub.php > > > > > > > > --_000_887FE7CFF6F8DE4BB3A9535F53AFD06AC31532CBilex2zendnet_--