Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58102 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84127 invoked from network); 27 Feb 2012 00:31:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2012 00:31:48 -0000 Authentication-Results: pb1.pair.com header.from=tom@punkave.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tom@punkave.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.210.170 as permitted sender) X-PHP-List-Original-Sender: tom@punkave.com X-Host-Fingerprint: 209.85.210.170 mail-iy0-f170.google.com Received: from [209.85.210.170] ([209.85.210.170:34013] helo=mail-iy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F0/17-40985-3FECA4F4 for ; Sun, 26 Feb 2012 19:31:48 -0500 Received: by iaeh11 with SMTP id h11so442881iae.29 for ; Sun, 26 Feb 2012 16:31:45 -0800 (PST) Received-SPF: pass (google.com: domain of tom@punkave.com designates 10.42.72.130 as permitted sender) client-ip=10.42.72.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tom@punkave.com designates 10.42.72.130 as permitted sender) smtp.mail=tom@punkave.com Received: from mr.google.com ([10.42.72.130]) by 10.42.72.130 with SMTP id o2mr7639376icj.8.1330302705644 (num_hops = 1); Sun, 26 Feb 2012 16:31:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.72.130 with SMTP id o2mr6309372icj.8.1330302705474; Sun, 26 Feb 2012 16:31:45 -0800 (PST) Received: by 10.231.108.135 with HTTP; Sun, 26 Feb 2012 16:31:45 -0800 (PST) In-Reply-To: References: <4F455C96.50706@gmail.com> <4F455E91.2060408@alliantinternet.com> <028001ccf1ab$0b200050$216000f0$@alliantinternet.com> <4F457517.7050901@alliantinternet.com> <028d01ccf230$91d79b00$b586d100$@alliantinternet.com> <4F4686C6.2040207@sugarcrm.com> <4F496818.8000405@sugarcrm.com> <4F4982BF.8090102@sugarcrm.com> Date: Sun, 26 Feb 2012 19:31:45 -0500 Message-ID: To: Kris Craig Cc: Arvids Godjuks , internals@lists.php.net Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmqc63Iz3wusWj8QZGFQ8dF5fCqCnhQLtJxpPLNsPZwQtJUGQPNRJFBSYZMUn5Gen7vg2im Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another) From: tom@punkave.com (Tom Boutell) There's no such thing as optional global anything, if you're a library or framework developer who has to cope with what's turned on wherever their code may wind up. On Sun, Feb 26, 2012 at 7:30 PM, Kris Craig wrote: > I actually agree as well. =9ALooking back in the thread, I think my overl= y > broad use of the word "strict" might have led to some confusion over what > I'm advocating. =9ASo to clarify, I'm referring to optional non-dynamic > typing vs purely dynamic typing as we have now. =9AStrict typing would > require some global or config setting as I originally proposed; a > function-by-function approach obviously would only work with weak typing. > =9ALooks like I got a bit dyslexic on you guys so I apologize for the > confusion. > > That being said, I do believe that optional strict typing on a global sca= le > is worthy of further discussion, though I remain on the fence as far as > whether or not we should actually go forward with that idea. =9ABut the > function-by-function approach (by which I mean weak typing lol) is > something that I'm increasingly convinced is a good idea. > > > --Kris > > > On Sun, Feb 26, 2012 at 4:09 PM, Arvids Godjuks wrote: > >> I absolutely agree with this. The hurdle with the strict type hinting is >> pictured very well. Strict is strict - either the whole codebase follows >> it, or it doesn't follow it at all. If a part of the code uses it - mean= s >> all the code comunicating with that part has to use, or at least has to = be >> written with the strict type hinting in mind. >> >> Oh, and i remembered a case where strict type hinting would be highly >> questionable - the "mixed" variant. Right now we document thouse with th= e >> phpdoc comments, but its quite common use in php to accept a null or an >> array for example. I can't imagine strict type hinting in this case, but >> weak type hints can work. >> 27.02.2012 0:51 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "John LeSueur" >> =CE=C1=D0=C9=D3=C1=CC: >> >> > [trim] >> > >> >> 2. "Strict type hinting would eliminate PHP's flexibility and take aw= ay >> >> its >> >> unique simplicity." >> >> >> >> I respectfully disagree. =9AAgain, let me remind you that we are *not= * >> >> talking >> >> about *converting *PHP to strict type hinting. =9AInstead, we're mere= ly >> >> talking about allowing PHP developers to *choose* whether or not to >> make a >> >> given function use dynamic or strict type hinting. =9AThe default beh= avior >> >> will remain dynamic, just as it is now. =9ABut there are situations w= here >> >> strict type hinting, even in a PHP script, would make more sense. =9A= There >> >> are many PHP developers, myself among them, who see considerable bene= fit >> >> in >> >> being able to make a function more condensed and streamlined without >> >> having >> >> to waste so much time on sanity checks that could instead be handled = at >> a >> >> lower level in the core. >> >> >> >> >> > So this is the argument that those who object to strict type hinting >> don't >> > agree with. Take the following: >> > >> > function strictTypes(/*int*/ $var) >> > { >> > =9A =9A //this is what the engine does if we have strict type checking >> > =9A =9A if(!is_int($var)) trigger_error(); >> > } >> > >> > function weakTypes(/*int*/ $var) >> > { >> > =9A =9A //this is what the engine does if we have weak type hinting, o= r >> > something similar. >> > =9A =9A if(!is_numeric($var) || (int)$var !=3D $var) trigger_error(); >> > =9A =9A else $var =3D (int)$var; >> > } >> > >> > function dynamicTypes($var) >> > { >> > =9A =9A strictTypes((int) $var); >> > =9A =9A //if $var is not an int, we just made it 0, and hid the type e= rror. >> > =9A =9A //to avoid this mistake we have to do: >> > =9A =9A strictTypes(is_int($var) ? $var : ((is_numeric($var) && (int)$= var =3D=3D >> > $var) ? (int)$var : trigger_error()); >> > =9A =9A //or something like it. >> > =9A =9A weakTypes($var); >> > =9A =9A //we'll get an error if $var can't be converted to an int with= out >> data >> > loss. >> > } >> > >> > By calling the strictTypes() function, the dynamicTypes() function >> > inherits the problem of validating the type of $var. Well, if I'm writ= ing >> > the dynamicTypes function, I don't want that work, so I push it up the >> > chain, and change my dynamicTypes function to statically typed. If you= 're >> > into static types, then you say, that's great, someone should make sur= e >> > that $var has the right type when they got it from the user. But if >> you're >> > not into static types, you were just forced to do type checking, eithe= r >> in >> > your code, or passing it up the call chain for someone else to do the >> type >> > checking. That's what is meant when we say dynamic typing can't really >> > coexist with strict typing. For those into dynamic types, weak type >> hinting >> > is much more palatable, because it doesn't require callers to adopt th= e >> > same philosophy. >> > >> > If you want type hinting, you'll have to specify which kind you want, >> > strict or weak. If it's strict type hinting, you'll need to convince e= ven >> > those who think dynamic typing is a guiding principle of PHP that it c= an >> be >> > done without forcing strict typing up the call chain. Weak type hintin= g >> is >> > a softer sell, but requires a lot of thought(much of which has been do= ne, >> > if you look in previous discussions) , about how and when to convert >> values. >> > >> --=20 Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com