Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53537 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63143 invoked from network); 23 Jun 2011 15:18:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jun 2011 15:18:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=neufeind@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=neufeind@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 91.184.32.3 as permitted sender) X-PHP-List-Original-Sender: neufeind@php.net X-Host-Fingerprint: 91.184.32.3 mail.speedpartner.de Linux 2.5 (sometimes 2.4) (4) Received: from [91.184.32.3] ([91.184.32.3:37684] helo=mail.speedpartner.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F2/D1-53684-E29530E4 for ; Thu, 23 Jun 2011 11:18:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.speedpartner.de (Postfix) with ESMTP id D0768B3C82 for ; Thu, 23 Jun 2011 17:18:02 +0200 (CEST) Received: from mail.speedpartner.de ([127.0.0.1]) by localhost (mail.speedpartner.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM11Ak8VBYbc for ; Thu, 23 Jun 2011 17:18:02 +0200 (CEST) Received: from collab.speedpartner.de (collab.speedpartner.de [91.184.32.10]) by mail.speedpartner.de (Postfix) with ESMTP id 87374B3ABB for ; Thu, 23 Jun 2011 17:18:02 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by collab.speedpartner.de (Postfix) with ESMTP id 7F18DFF0003 for ; Thu, 23 Jun 2011 17:18:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at collab.speedpartner.de Received: from collab.speedpartner.de ([127.0.0.1]) by localhost (collab.speedpartner.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAbqNxQ3cHlT for ; Thu, 23 Jun 2011 17:18:00 +0200 (CEST) Received: from sn-dell.local.neufeind.net (ip-62-143-29-72.unitymediagroup.de [62.143.29.72]) by collab.speedpartner.de (Postfix) with ESMTPSA id 08244FF0002 for ; Thu, 23 Jun 2011 17:18:00 +0200 (CEST) Message-ID: <4E035929.8030109@php.net> Date: Thu, 23 Jun 2011 17:18:01 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10 MIME-Version: 1.0 To: internals@lists.php.net References: <4E0355AE.4080305@php.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Variable scopes for language constructs (foreach, ...) From: neufeind@php.net (Stefan Neufeind) On 06/23/2011 05:09 PM, Ferenc Kovacs wrote: > On Thu, Jun 23, 2011 at 5:03 PM, Stefan Neufeind wrote: > >> 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 [...] >> (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. [...] > it was discussed many times on the list, That's what I feared. > 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()." Yes, I should have included that reference. While it's in the docs, I don't think many people know about it. As said, with normal variables it's no real problem either (forgetting about a $temp-variable). But with references it becomes a problem. We've introduced some reference-usage in TYPO3-project lately and that's where somebody mentioned "remember to use unset()", which I wasn't really aware of I must admit. > personally I find that weird, and unintuitive, but changin that in a major > or minor version could be changed if we chose to. I think it's a behaviour that could be changed in some step like from 5.3 to 5.4 or so. Personally I don't think it would influence existing implementations much (who uses the key/value of a foreach after the loop?) or could easily be changed. While the new behavior might sound "weird" at first sight, it partially replicates scoping that other languages already do. And (especially for the references-case) it might even prevent some unplanned, maybe hard to debug problems (if you forget to unset()). Kind regards, Stefan