Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58357 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 418 invoked from network); 29 Feb 2012 22:15:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 22:15:42 -0000 Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 74.125.82.170 mail-we0-f170.google.com Received: from [74.125.82.170] ([74.125.82.170:34592] helo=mail-we0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1E/0B-46815-D83AE4F4 for ; Wed, 29 Feb 2012 17:15:41 -0500 Received: by werh12 with SMTP id h12so2912002wer.29 for ; Wed, 29 Feb 2012 14:15:38 -0800 (PST) Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.216.139.12 as permitted sender) client-ip=10.216.139.12; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kris.craig@gmail.com designates 10.216.139.12 as permitted sender) smtp.mail=kris.craig@gmail.com; dkim=pass header.i=kris.craig@gmail.com Received: from mr.google.com ([10.216.139.12]) by 10.216.139.12 with SMTP id b12mr1204114wej.4.1330553738951 (num_hops = 1); Wed, 29 Feb 2012 14:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r0avUXqfk728DgMWcwB5lxbnloPm8rcSwqoMfN67v4k=; b=PaLn6MP94pLRLcry+8abG5q+WqifH4PkdhSab5QfrXfRxPUFVLKf+ZUeetsKdJp+hQ ppoAMFgeh7SPWRw/1wPopIpVBbcRf0LTUGEY0o6u5UxwaaPJ9eoW34bnmmzreNxQFs+p uMDeHf53cmqJNsvwL4csihnhb6f81hLLglXQQ= MIME-Version: 1.0 Received: by 10.216.139.12 with SMTP id b12mr972402wej.4.1330553738762; Wed, 29 Feb 2012 14:15:38 -0800 (PST) Received: by 10.223.75.146 with HTTP; Wed, 29 Feb 2012 14:15:38 -0800 (PST) In-Reply-To: <887FE7CFF6F8DE4BB3A9535F53AFD06AC3152F5D@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> Date: Wed, 29 Feb 2012 14:15:38 -0800 Message-ID: To: Zeev Suraski Cc: John Crenshaw , Richard Lynch , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=0016e6d62574f41aed04ba21ae3f Subject: Re: [PHP-DEV] Scalar type hinting From: kris.craig@gmail.com (Kris Craig) --0016e6d62574f41aed04ba21ae3f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Responses inline. --Kris On Wed, Feb 29, 2012 at 1:49 PM, Zeev Suraski wrote: > Kris,**** > > ** ** > > If we=92ve agreed that strict typing is bad, why is it even showing on th= e > discussion here? Calling it =91firm=92 or =91strong=92 doesn=92t make a = difference. > If it errors out or throws an exception (which BTW is out of the question > for a language feature), it=92s strict typing, regardless of naming. > That is a form of cognitive dissonance, a logical fallacy. More colloquially 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 > because 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 doesn't give you the right to demand that we cease talking about it just because *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 designed to silence dissenting views from being introduced and discussed. The rationale behind that time period was to allow for cases where there > was an =91almost=92 majority. Here, the proposal stands no chance. The = only > reason you=92re not seeing anybody from the core devs responding is becau= se > they=92re tired of the Nth incarnation of the same discussion happening a= gain > with zero new ideas. > Please refer to the Wikipedia link I posted above pertaining to "weasel words." Just because a conceptually similar proposal failed two years ago doesn't mean 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 = 2 > nd bullet, that is:**** > > The author(s) make substantial changes to the proposal. While it's > impossible 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.**** > > ** ** > > =85 then it=92s worth discussing. Nothing I saw in this thread falls und= er > that category, as far as I can tell. > I disagree. A number of ideas have been put forth that differ from previous proposals. Just because *you* don't think they differ enough does not mean you can unilaterally declare that this discussion must end. Besides, as you said, such a standard would be completely arbitrary and open to interpretation. 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 rest 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 typically operates, and we all know how effective they are.... **** > > ** ** > > Let=92s put it to rest. > This issue isn't going away. Again, we've already addressed this in previous posts. You may not want to discuss it, and there may be people who share your sentiment, but that does not give you the authority to shut down this 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 promised 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 location 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 soon 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 > into 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 > an RFC is rejected, the policy does allow it to be re-introduced after 6 > months. While we're not actually reviving a previously rejected RFC sinc= e > we're discussing a different approach, even if you were to apply that to > the broader conceptual level, this discussion is still perfectly kosher > since, as you said, that rejection happened 1.5 years ago (3 times the > required period). > > > Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed > at this repetitive pattern by now. We start finding common ground and > making progress, then somebody new makes a post about the evils of strict > typing and questioning why we're talking about this, obviously completely > ignoring the fact that we've already addressed this *numerous* times. So > Zeev, while I appreciate your interest and welcome you to participate, > please take another look at the previous posts in this thread, because we > have already addressed 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 you 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 > over the last ~1.5years that warrants a new discussion into that matter. > I think the previous discussion ended with a pretty clear directive that > strict 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 ask you guys not to call the 5.4 release PHP." - which put in one > sentence what several others (myself included) put in many more words. S= o > the 'strong'/'firm'/'strict'/whatnot version of what is being discussed > here, should probably not be discussed at all. We've been through it, an= d > 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, a= nd > 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 want to revive that discussion, I suggest you take a lo= ok > at that RFC - confine yourselves to only work on stuff that stands a chan= ce > to get accepted (no strict typing) - and try to come up with good answers > to the open questions. 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= _id > > > > =3DF > > > > S9NLTNEEKWBE > > > > > > > > > > > > > > > > -- > > > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe= , > > > > visit: http://www.php.net/unsub.php > > > > > > > > > > >**** > > ** ** > --0016e6d62574f41aed04ba21ae3f--