Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58176 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 32738 invoked from network); 27 Feb 2012 19:17:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2012 19:17:05 -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.54 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 74.125.82.54 mail-ww0-f54.google.com Received: from [74.125.82.54] ([74.125.82.54:41322] helo=mail-ww0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9E/90-29394-EA6DB4F4 for ; Mon, 27 Feb 2012 14:17:03 -0500 Received: by wgbdq13 with SMTP id dq13so521417wgb.11 for ; Mon, 27 Feb 2012 11:16:59 -0800 (PST) Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.180.24.166 as permitted sender) client-ip=10.180.24.166; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kris.craig@gmail.com designates 10.180.24.166 as permitted sender) smtp.mail=kris.craig@gmail.com; dkim=pass header.i=kris.craig@gmail.com Received: from mr.google.com ([10.180.24.166]) by 10.180.24.166 with SMTP id v6mr21721307wif.10.1330370219596 (num_hops = 1); Mon, 27 Feb 2012 11:16:59 -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=KcMQmST5Y/scqrFQCQh3a8Ih52lXbb92ip1FWyDrpWc=; b=skt9QgeN2/+X05XUmVGXZh3mb1E1DM36xuOUdJnTbgxICbfRbKpqL4ZrKAI/IwnYUe sgeN8SL7G1ArD1aX3tbaA5j0y1Pw8CvLxtDHY5c2Qhvzie3lLITy+xxn+QoYLbk255Om sc4LEvifMXGykaa5L8dUEWpEL6GQHOxa/G0fE= MIME-Version: 1.0 Received: by 10.180.24.166 with SMTP id v6mr17112793wif.10.1330370219462; Mon, 27 Feb 2012 11:16:59 -0800 (PST) Received: by 10.223.75.146 with HTTP; Mon, 27 Feb 2012 11:16:59 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> Date: Mon, 27 Feb 2012 11:16:59 -0800 Message-ID: To: Anthony Ferrara Cc: Ferenc Kovacs , Michael Morris , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=f46d0418261059d13304b9f6f4f5 Subject: Re: [PHP-DEV] Scalar type hinting From: kris.craig@gmail.com (Kris Craig) --f46d0418261059d13304b9f6f4f5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Err typo correction: "Strong, on the other hand, would throw a fatal error if you attempted to pass an incompatible value to *a variable." (not "an array") --Kris On Mon, Feb 27, 2012 at 11:15 AM, Kris Craig wrote: > 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 an= other > way, if the "converted" value does not match the original value. For > example, if 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 othe= r hand, > if you were to pass the string "1" to that integer variable, it would > convert to 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= display > a notice though? Or no error at all? I can think of reasonable argum= ents > 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 needle= ss >> 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 appe= ase >> 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 typi= ng >> 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 wr= ote: >> >>> > no, it is: "come back after you did your homework, and you can provid= e >>> 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+typi= ng&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 thi= s 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 < >>> dmgx.michael@gmail.com>wrote: >>> > >>> >> So the official response is "get lost"? >>> >> >>> >> >>> > no, it is: "come back after you did your homework, and you can provid= e >>> 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 >>> sense >>> > 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 passin= g >>> the >>> > expected types (notice that strict typing would pass that burden to >>> the 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 >>> >>> >> > --f46d0418261059d13304b9f6f4f5--