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 = false;
foreach ($array1 as $value) {
$good = $good & $value;
}
unset($good);
foreach ($array2 as $value) {
$good = $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 <tyr...@gmail.com> wrote:
> On Thu, Jun 23, 2011 at 5:03 PM, Stefan Neufeind <neufe...@php.net> 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) {
>> // ...
>> $found = true;
>> }
>> if($found) {
>> // ...
>> }
>>
>> (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) {
>> // ...
>> }
>> // ...
>> $temp = 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 var $found somewhere inside a function to allow
>> things like
>>
>> if($a) {
>> var $temp;
>>
>> $temp = 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 major
> 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
