Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53536 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62887 invoked from network); 23 Jun 2011 15:17:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jun 2011 15:17:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.170 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 74.125.83.170 mail-pv0-f170.google.com Received: from [74.125.83.170] ([74.125.83.170:41731] helo=mail-pv0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8A/C1-53684-529530E4 for ; Thu, 23 Jun 2011 11:17:57 -0400 Received: by pvh10 with SMTP id 10so1251520pvh.29 for ; Thu, 23 Jun 2011 08:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tBqOzBNG0tEyPgrh+cekliGZR8WsDyoa86gPdAtUmU8=; b=f29iGgNY/cRBysaj2vwq0YqgbnkLlHAPO0XqWvpil3RTqh+f+s1IGWil5eND2GlmJ0 B63mBCuja8p5Pm7jjMpYfm++HywDBERC5IaWcOUYT8vw0CqxozTZgGnIYveI4sNV1dms uqB+kjTAAqAltTU5qUjZopxDRvlVsQA3bMpfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xQq8oPQa6k0/yZ/eRPpvupDrLALRPNYtRcQpSYMBluMUDqMYzbr7X96OhTXWNqEDrF bSzybDSN9zlZCtZAiXVhUqWHFhbqGi8T0fUrA1wRTZILquYKaNtnOmOYsOZsBEDUsuPT qo6WVrSsRHYdY5Wr/cnFZ4vDD4qqNjFlA4fWo= MIME-Version: 1.0 Received: by 10.68.27.69 with SMTP id r5mr1098468pbg.382.1308842273084; Thu, 23 Jun 2011 08:17:53 -0700 (PDT) Received: by 10.68.56.104 with HTTP; Thu, 23 Jun 2011 08:17:53 -0700 (PDT) In-Reply-To: References: <4E0355AE.4080305@php.net> Date: Thu, 23 Jun 2011 11:17:53 -0400 Message-ID: To: Ferenc Kovacs Cc: Stefan Neufeind , internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Variable scopes for language constructs (foreach, ...) From: ircmaxell@gmail.com (Anthony Ferrara) Personally, I don't care for the concept of a block scope. I do understand that it can have benefits and make certain tasks easier. But it can also lead to weird bugs and inconsistencies. For example, take the following code: $good =3D false; foreach ($array1 as $value) { $good =3D $good & $value; } unset($good); foreach ($array2 as $value) { $good =3D $value; } var_dump($good); What's the value of the dump? Should it be null? Should it be the last element of array2? Why? We now have the ability to close around scopes, so I fail to see the reason to do this. If you want a separate scope, then do an extract method on the loop. Pull it out to another method and be done. It'll be cleaner anyway. Besides, if you buy the arguments made in most clean code books, you shouldn't have more than 1 block in a single function anyway (as then it starts to do too much). So the scoping issue becomes pointless at that point. Injecting unsets and including a block scope have the ability to make some very functional code not work anymore. And for non-obvious reasons. I guess I just fail to see the true need for a block level scope. Sure there are benefits, but the benefits I can see are nullified by re-factoring techniques. Just my 0.02. Anthony On Thu, Jun 23, 2011 at 11:09 AM, Ferenc Kovacs wrote: > On Thu, Jun 23, 2011 at 5:03 PM, Stefan Neufeind wrote= : > >> Hi, >> >> I've lately discussed with a colleague which scopes of variables exist >> for PHP or would probably make sense. In general I think the general >> idea of having variables available all throughout a function is okay as >> this allows things like >> >> foreach($vals as $v) { >> =A0// ... >> =A0$found =3D true; >> } >> if($found) { >> =A0// ... >> } >> >> (setting $found inside the loop while still being able to access it >> outside) >> >> But the interesting part is that $v is also still available outside the >> loop (last value). While most people would say this is not a big >> problem, it can become problematic when using references. >> >> foreach($vals as &$temp) { >> =A0// ... >> } >> // ... >> $temp =3D 5; >> (when you don't think about the reference anymore but want some >> temp-variable) >> >> >> If this has been "throughly discussed" before, please excuse. But if not >> maybe somebody could share his oppinion on the following proposal. >> >> What if we (for example with PHP 5.4 or if not possible maybe with the >> next one) change the behaviour so that >> >> * variables used for key/value in foreach (probably other places?) would >> be limited to that loop-scope >> >> and maybe >> * variable $found in the first example would need to be initialised >> before the loop. Otherwise it would be a new variable inside the scope >> of foreach that would be gone afterwards >> >> and/or maybe >> * allowing to explicitly limit variable-scopes inside blocks, for >> example by allowing =A0 =A0var $found =A0 somewhere inside a function to= allow >> things like >> >> if($a) { >> =A0var $temp; >> >> =A0$temp =3D 5; >> } >> // and $temp would be gone here; was limited to the scope in which it >> was defined by var >> >> >> Hope this is not too much of a non-sense idea to you :-) >> >> > Hi, > > it was discussed many times on the list, and this behavior is also > documented, see > http://php.net/manual/en/control-structures.foreach.php > > "Reference of a $value and the last array element remain even after the > foreach loop. It is recommended to destroy it by unset()." > > personally I find that weird, and unintuitive, but changin that in a majo= r > or minor version could be changed if we chose to. > > Tyrael >