Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53546
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
DomainKey-Status: bad
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=DOk7Rck5T8eACb7v5/qJfEhLNRRkwAnkjrioK4JzLMSzVAgm7h9HN2+EaXwVeJiW7c
         5yN4TPx6SJrHzM0EbGpkRi+tUCxtIFx8SymOnig1NsZ7dFzpSrg39jIG39diyE4jOsb3
         vDg6TTiWElR1RYQzZjLRZ1tspZxdBw2RvYp5Y=
MIME-Version: 1.0
In-Reply-To: <4E035B7E.4010703@php.net>
References: <4E0355AE.4080305@php.net>
	<BANLkTikZnu=4HzrrojWs1atq_RYJZRBmYQ@mail.gmail.com>
	<BANLkTinp849pHv5D9CfgwJLcMp=L+qBPcg@mail.gmail.com>
	<4E035B7E.4010703@php.net>
Date: Thu, 23 Jun 2011 11:46:18 -0400
Message-ID: <BANLkTik4EfAYjCphKRSJ4+rqZUEL7S92pQ@mail.gmail.com>
To: Stefan Neufeind <neufeind@php.net>
Cc: 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)

> You can always argue that creating smaller methods (like "no methods
> with more than 100 lines" or so) would limit the problems of a forgotten
> (not unset()) reference-variable. But imho that's not the point.

It is the point.  Should we support a feature that will not help those
who are following best practices?  (That's an honest question)...

You *could* make the argument that scoping is not a trivial concept to
understand.  My guess is that the majority of people who would get
caught up by this "issue" also would not understand the scoping
change.  So that means that the change would only benefit those who
actually understand what they are doing, but aren't following best
practices (for whatever reason).

I'm not trying to insult anyone with that statement.  I'm just trying
to show that there's a band of usefulness here.  People who are new or
junior will be hampered by this change (I can see the bug reports now,
I set the variable but it's not getting set!).  Some people will
benefit from it.  But those who are following best practices (design
and architecture wise at least) will not benefit from it because they
don't have a need for it.

So the question I have is such: Is the benfit to that band of users
worth the change and any possible negatives it has?  Especially
considering the exact same functionality can be achieved by doing a
simple extract method re-factor.

Anthony

PS: I consider 100 line methods to be large.  Sure, they are not
gigantic, but they are large.  My current coding standards have a soft
cap at 20 lines, and a hard cap at 50 lines (which must be justified
in a formal code review).  My personal belief and experience is that
if you have more than 20 lines or so, you're likely trying to do too
much (and violating SRP).  There is a difference between good and good
enough, but just putting it out there...

On Thu, Jun 23, 2011 at 11:27 AM, Stefan Neufeind <neufeind@php.net> wrote:
> On 06/23/2011 05:17 PM, Anthony Ferrara wrote:
>> Personally, I don't care for the concept of a block scope. =A0I do
>> understand that it can have benefits and make certain tasks easier.
>> But it can also lead to weird bugs and inconsistencies. =A0For example,
>> take the following code:
>>
>> $good =3D false;
>>
>> foreach ($array1 as $value) {
>> =A0 =A0 $good =3D $good & $value;
>> }
>>
>> unset($good);
>>
>> foreach ($array2 as $value) {
>> =A0 =A0 $good =3D $value;
>> }
>>
>> var_dump($good);
>>
>> What's the value of the dump? =A0Should it be null? =A0Should it be the
>> last element of array2? =A0Why?
>
> From my feeling it would be the present outside of the first
> foreach()-loop right before the unset() since the variable was created
> outside the foreach() already. Then it was unset (doesn't exist) and
> recreated inside the second foreach-loop.
>
> If you even wanted to explicitly say that you don't want to go for the
> outside-visibile $good then, as proposed, you could use some
>
> var $good;
>
> inside the foreach-loop imho to declare that you want a new variable
> only visible inside the block. When that ends the outside-visibile $good
> would be used again.
>
> In case of "clean programming" the $good before the first example would
> be there anyhow if somebody wants to rely on $good having a value after
> the first foreach().
>
>> We now have the ability to close around scopes, so I fail to see the
>> reason to do this. =A0If you want a separate scope, then do an extract
>> method on the loop. =A0Pull it out to another method and be done. =A0It'=
ll
>> be cleaner anyway. =A0Besides, 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). =A0So the scoping
>> issue becomes pointless at that point.
>
> You can always argue that creating smaller methods (like "no methods
> with more than 100 lines" or so) would limit the problems of a forgotten
> (not unset()) reference-variable. But imho that's not the point.
>
>
> Kind regards,
> =A0Stefan Neufeind
>
>> On Thu, Jun 23, 2011 at 11:09 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote=
:
>>> On Thu, Jun 23, 2011 at 5:03 PM, Stefan Neufeind <neufeind@php.net> wro=
te:
>>>
>>>> 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 a=
s
>>>> 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 th=
e
>>>> 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 n=
ot
>>>> 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?) wou=
ld
>>>> 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 ma=
jor
>>> or minor version could be changed if we chose to.
>>>
>>> Tyrael
>>>
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>