Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58174 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31207 invoked from network); 27 Feb 2012 19:15:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2012 19:15:33 -0000 Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 209.85.212.170 mail-wi0-f170.google.com Received: from [209.85.212.170] ([209.85.212.170:58640] helo=mail-wi0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8A/40-29394-356DB4F4 for ; Mon, 27 Feb 2012 14:15:32 -0500 Received: by wibhm4 with SMTP id hm4so3502488wib.29 for ; Mon, 27 Feb 2012 11:15:29 -0800 (PST) Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.180.99.100 as permitted sender) client-ip=10.180.99.100; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kris.craig@gmail.com designates 10.180.99.100 as permitted sender) smtp.mail=kris.craig@gmail.com; dkim=pass header.i=kris.craig@gmail.com Received: from mr.google.com ([10.180.99.100]) by 10.180.99.100 with SMTP id ep4mr31060259wib.7.1330370129181 (num_hops = 1); Mon, 27 Feb 2012 11:15:29 -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=oJEXrpAvH0GrrobQEctd0Xb3SbWYJ9zESrGoDZEujBI=; b=WJ7+GJpGy0mkvDA+6FRUVdiLtWUgzrppUFCkkuiY22Ib20eQXsmhGZBfvE7akAexq6 UAwZW0T5ZMlkDFulEhYuH/QdB9pE3EltYZt/4ykVokfo9k72e6a2QquvuXpThis2F4Jz wtsnm3TZCvNCVHkvN9To6vwbIglvlhRq8wAq8= MIME-Version: 1.0 Received: by 10.180.99.100 with SMTP id ep4mr24639429wib.7.1330370129038; Mon, 27 Feb 2012 11:15:29 -0800 (PST) Received: by 10.223.75.146 with HTTP; Mon, 27 Feb 2012 11:15:28 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> Date: Mon, 27 Feb 2012 11:15:28 -0800 Message-ID: To: Anthony Ferrara Cc: Ferenc Kovacs , Michael Morris , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=f46d04428e5cf60d8204b9f6eeb0 Subject: Re: [PHP-DEV] Scalar type hinting From: kris.craig@gmail.com (Kris Craig) --f46d04428e5cf60d8204b9f6eeb0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Now, to rewind a bit past the latest chunk of "I hate this idea" posts.... I'd like to suggest a new term: "strong". This term would be similar to "weak", except with a few key differences: - Weak would behave very much like Arvids suggested in his earlier post; i.e. if the variable is an integer but you pass a string (like "aaa") to it, a warning would be thrown and PHP would attempt to convert it (i.e. = it would become 1). - Strong, on the other hand, would throw a fatal error if you attempted to pass an incompatible value to an array. Or, to put it another way, i= f the "converted" value does not match the original value. For example, i= f we're assigning "aaa" to an integer, that would convert to 1; and, since "1" !=3D "aaa", a fatal error would be thrown. On the other hand, if yo= u were to pass the string "1" to that integer variable, it would convert t= o 1; and, since "1" =3D=3D 1, there wouldn't be a problem. - In both instances, if the converted value matches the original (i.e. "1" =3D=3D 1), no warning error would be displayed. Should it perhaps d= isplay a notice though? Or no error at all? I can think of reasonable argumen= ts on both sides of that question. This new term would also make it easier for us to avoid using the term "strict," which would explode even in the case of "1" =3D=3D 1. Whether this should be done at the function level, the variable level, or both is an open-ended question. Some possible examples of how this would look: weak int $i =3D "aaa"; // Converts to 1 and throws a warning. strong int $ii =3D "aaa"; // Throws a fatal error. weak int $i =3D "1"; // Converts to 1. strong int $ii =3D "1"; // Converts to 1. --Kris On Mon, Feb 27, 2012 at 10:53 AM, Kris Craig wrote: > +1 what Anthony said. > > Guys, seriously. Some of these responses have been downright rude and > inappropriate for a constructive dialogue. Please do not pollute this > thread with cliche, "Just find another language and get out!" posts. It > doesn't add anything to the conversation and instead just creates needles= s > anger and animosity. It's immature and just makes it look like we're > incapable of having a rational discussion. > > So, let me outline a list of "arguments" that will carry ZERO weight on > this thread: > > - "If you don't like PHP as it is, goto Java (or some other language)!= " > - "We've already talked about this before. Therefore, we must never > speak of it again." > - "This is impossible. Why? Because I said so. You want evidence? > Fuck you." > - "But this would require significant changes to the core source > code! We'd never be able to find enough sacrificial penguins to appea= se > the gods!" > - "Anyone who likes this idea is either stupid or not a 'true' PHP > developer." > - "If you disagree with me, it means you haven't done your homework > because I'm always right." > - "Strict typing would break everything! What? You're not talking > about C-like strict typing? Sorry, I didn't catch that. Strict typin= g > would break everything!...." > - "I don't care if you've already countered my argument. I'll just > keep repeating myself as if you didn't." > > > Variations of the above statements have been posted ad nauseum. They're > all based on logical fallacies and are not constructive. > > I'm putting this out there: If anyone posts one or more of the above > arguments yet again on this topic, I will personally extract one of your > kidneys and sell it to a questionable "dog food" company in Shanghai. I > will then openly mock your intellectual laziness and encourage people to > ignore you. ;P > > > I'd love to prove Daniel wrong, but I think he may be on to something.... > :\ > > --Kris > > > > On Mon, Feb 27, 2012 at 9:38 AM, Anthony Ferrara wro= te: > >> > no, it is: "come back after you did your homework, and you can provide >> new >> > arguments to the discussion" >> >> >> To be completely fair, I did homework on this. I went back to 2000 on >> marc.info's archives and read almost all of the 400 posts matching the >> search http://marc.info/?l=3Dphp-internals&w=3D2&r=3D13&s=3Dstrict+typin= g&q=3Db >> and a bunch of the posts on >> http://marc.info/?l=3Dphp-internals&w=3D2&r=3D54&s=3Dtype+hinting&q=3Db >> >> The vast majority of what I found were quite good arguments for >> including the feature. I found quite a bit of "this was discussed to >> death, do your homework and provide new arguments". What's odd, is >> that one of the earliest on-topic threads that I found (2007: >> http://marc.info/?l=3Dphp-internals&m=3D119514660125258&w=3D2 ) had this= as >> the third reply. The only on-topic discussion that I found prior to >> that was in 2006 (almost exactly 1 year prior: >> http://marc.info/?l=3Dphp-internals&m=3D116257685415135&w=3D2 ). >> >> Discussed to death. Yet only one time before (discussing a specific >> patch)... >> >> And the opponents still said no... >> >> There were also quite a few problems identified with scalar hinting >> and auto-casting vs strict erroring. However, there were also >> solutions proposed to nearly each and every one of them. >> >> And the opponents still said no... >> >> It has been brought up time and time again. Solutions have been >> proposed which have no fundimental issues (inconsistencies, >> problematic operations - such as references, etc)... >> >> And the opponents instead said "this has been discussed to death, no"... >> >> Please can you stop saying "this has been discussed to death". To be >> frank, don't stop the discussion because you don't like the idea. It >> has been discussed to death. But the discussion has only really ever >> involved people who are for it. The opponents by and large have used >> two arguments: "It has been discussed already, so no" and "don't make >> PHP into Java". >> >> There has been some discussion of technical merit and problem >> resolution by opponents, but finding it is VERY difficult among all >> the down trodding commentary. >> >> So let me make a plea: >> >> If you don't like this feature, and you can explain from a TECHNICAL >> perspective why, please do so! If you don't like the feature, and are >> going to lean on "It's not Java", or "We've discussed this to death >> already", please don't... >> >> >> >> And to be fair: "and you can provide new arguments to the discussion" >> has already happened quite a bit (dating back the past 5 years), but >> those arguments were ignored or overruled for political reasons. >> >> >> Anthony >> >> >> On Mon, Feb 27, 2012 at 11:55 AM, Ferenc Kovacs wrote= : >> > On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris > >wrote: >> > >> >> So the official response is "get lost"? >> >> >> >> >> > no, it is: "come back after you did your homework, and you can provide >> new >> > arguments to the discussion" >> > >> > >> > >> >> I don't know about the internals implications. But from an external >> >> API standpoint I see no problem in allowing programmers who want to >> >> strictly enforce a variable's datatype to do so. Legacy code would >> >> not be affected unless it was trying to use the new reserved word >> >> "strict" >> >> >> >> >> > it was discussed before, strict typing tends to be "viral", in the sen= se >> > that the developer using a lib which enforces method signatures using >> type >> > hinting can either: >> > - write a lot of boiler plate code to make sure that he/she is passing >> the >> > expected types (notice that strict typing would pass that burden to th= e >> api >> > consumer, which is against the Generous on input, strict on output >> > paradigm, plus it would generate much more work, as there are always >> more >> > consumers than producers) >> > - or simply passing those requirements up in the call chain, which is >> less >> > work, but affects even more code, and in the end, turns the whole app >> into >> > strict typing. >> > >> > -- >> > Ferenc Kov=E1cs >> > @Tyr43l - http://tyrael.hu >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > --f46d04428e5cf60d8204b9f6eeb0--