Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58103 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85411 invoked from network); 27 Feb 2012 00:33:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2012 00:33:47 -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:42146] helo=mail-we0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9D/57-40985-A6FCA4F4 for ; Sun, 26 Feb 2012 19:33:47 -0500 Received: by werh12 with SMTP id h12so482681wer.29 for ; Sun, 26 Feb 2012 16:33:44 -0800 (PST) Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.180.99.7 as permitted sender) client-ip=10.180.99.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kris.craig@gmail.com designates 10.180.99.7 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.7]) by 10.180.99.7 with SMTP id em7mr23235301wib.7.1330302824209 (num_hops = 1); Sun, 26 Feb 2012 16:33:44 -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=KWp3m6YVB6YWiACqYbblZWa2PQs7N0eKIRapSuYq6e0=; b=tdlsDAD9hn4foRjIHhUbQX50E0HPBqn1DB82jf9xhwo6rwvO9HNpQhoHMYYTdC2i5k lXTOD/YBkEIxcqxo3eSCsgj4gFa3wOtSv0FONHzGxrC/kSFJLD6te5yh9aGcNMS8mwA7 S6AlZwZqk2oP7aOuwZ9ynrYNkFnAKFc6xvxUE= MIME-Version: 1.0 Received: by 10.180.99.7 with SMTP id em7mr18494968wib.7.1330302824025; Sun, 26 Feb 2012 16:33:44 -0800 (PST) Received: by 10.223.75.146 with HTTP; Sun, 26 Feb 2012 16:33:43 -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 16:33:43 -0800 Message-ID: To: Tom Boutell Cc: Arvids Godjuks , internals@lists.php.net Content-Type: multipart/alternative; boundary=f46d04182804450ce304b9e74350 Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another) From: kris.craig@gmail.com (Kris Craig) --f46d04182804450ce304b9e74350 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Exactly, hence why I'm still on the fence with that. I was hoping for some further discussion though to see if anyone can think of a way around that, though admittedly nothing comes to my mind. --Kris 2012/2/26 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. Looking back in the thread, I think my overl= y > > broad use of the word "strict" might have led to some confusion over wh= at > > I'm advocating. So to clarify, I'm referring to optional non-dynamic > > typing vs purely dynamic typing as we have now. Strict typing would > > require some global or config setting as I originally proposed; a > > function-by-function approach obviously would only work with weak typin= g. > > Looks 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 > scale > > 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. But 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 < > arvids.godjuks@gmail.com>wrote: > > > >> I absolutely agree with this. The hurdle with the strict type hinting = is > >> pictured very well. Strict is strict - either the whole codebase follo= ws > >> it, or it doesn't follow it at all. If a part of the code uses it - > means > >> all the code comunicating with that part has to use, or at least has t= o > 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 > the > >> phpdoc comments, but its quite common use in php to accept a null or a= n > >> array for example. I can't imagine strict type hinting in this case, b= ut > >> 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 > away > >> >> its > >> >> unique simplicity." > >> >> > >> >> I respectfully disagree. Again, let me remind you that we are *not= * > >> >> talking > >> >> about *converting *PHP to strict type hinting. Instead, 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. The default > behavior > >> >> will remain dynamic, just as it is now. But there are situations > where > >> >> strict type hinting, even in a PHP script, would make more sense. > There > >> >> are many PHP developers, myself among them, who see considerable > benefit > >> >> in > >> >> being able to make a function more condensed and streamlined withou= t > >> >> having > >> >> to waste so much time on sanity checks that could instead be handle= d > 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) > >> > { > >> > //this is what the engine does if we have strict type checking > >> > if(!is_int($var)) trigger_error(); > >> > } > >> > > >> > function weakTypes(/*int*/ $var) > >> > { > >> > //this is what the engine does if we have weak type hinting, or > >> > something similar. > >> > if(!is_numeric($var) || (int)$var !=3D $var) trigger_error(); > >> > else $var =3D (int)$var; > >> > } > >> > > >> > function dynamicTypes($var) > >> > { > >> > strictTypes((int) $var); > >> > //if $var is not an int, we just made it 0, and hid the type > error. > >> > //to avoid this mistake we have to do: > >> > strictTypes(is_int($var) ? $var : ((is_numeric($var) && (int)$va= r > =3D=3D > >> > $var) ? (int)$var : trigger_error()); > >> > //or something like it. > >> > weakTypes($var); > >> > //we'll get an error if $var can't be converted to an int withou= t > >> data > >> > loss. > >> > } > >> > > >> > By calling the strictTypes() function, the dynamicTypes() function > >> > inherits the problem of validating the type of $var. Well, if I'm > writing > >> > the dynamicTypes function, I don't want that work, so I push it up t= he > >> > chain, and change my dynamicTypes function to statically typed. If > you're > >> > into static types, then you say, that's great, someone should make > sure > >> > 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, > either > >> in > >> > your code, or passing it up the call chain for someone else to do th= e > >> type > >> > checking. That's what is meant when we say dynamic typing can't real= ly > >> > coexist with strict typing. For those into dynamic types, weak type > >> hinting > >> > is much more palatable, because it doesn't require callers to adopt > the > >> > 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 > even > >> > those who think dynamic typing is a guiding principle of PHP that it > can > >> be > >> > done without forcing strict typing up the call chain. Weak type > hinting > >> is > >> > a softer sell, but requires a lot of thought(much of which has been > done, > >> > if you look in previous discussions) , about how and when to convert > >> values. > >> > > >> > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > --f46d04182804450ce304b9e74350--