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 :-)
Kind regards,
Stefan
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 likeforeach($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-scopeand 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 afterwardsand/or maybe
- allowing to explicitly limit variable-scopes inside blocks, for
example by allowing var $found somewhere inside a function to allow
things likeif($a) {
var $temp;$temp = 5;
}
// and $temp would be gone here; was limited to the scope in which it
was defined by varHope 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
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 likeforeach($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-scopeand 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 afterwardsand/or maybe
- allowing to explicitly limit variable-scopes inside blocks, for
example by allowing var $found somewhere inside a function to allow
things likeif($a) {
var $temp;$temp = 5;
}
// and $temp would be gone here; was limited to the scope in which it
was defined by varHope 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.
I would like to see, in a future version, the local var of the foreach()'s
refcount being dropped to 0 or something similar. Unless it is a
by-reference variable in which case it should remain untouched.
Tyrael
Martin Scotta
On Thu, Jun 23, 2011 at 12:12 PM, Paul Dragoonis dragoonis@gmail.comwrote:
On Thu, Jun 23, 2011 at 5:03 PM, Stefan Neufeind neufeind@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 likeforeach($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-scopeand 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 afterwardsand/or maybe
- allowing to explicitly limit variable-scopes inside blocks, for
example by allowing var $found somewhere inside a function to
allow
things likeif($a) {
var $temp;$temp = 5;
}
// and $temp would be gone here; was limited to the scope in which it
was defined by varHope 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.I would like to see, in a future version, the local var of the foreach()'s
refcount being dropped to 0 or something similar. Unless it is a
by-reference variable in which case it should remain untouched.Tyrael
Also I've love to be able to....
$var = 'global';
class Foo {
private $var = 'member';
function test1() {
return $var;
}
function test2($var='param') {
return $var;
}
function test3() {
$var = 'variable';
return $var;
}
function test4() {
global $var;
return $var;
}
}
$foo = new Foo();
var_dump( $foo->test1() ); // member
var_dump( $foo->test2() ); // param
var_dump( $foo->test3() ); // variable
var_dump( $foo->test4() ); // global
From a "language" POV this seems very possible.
Is it possible from a core POV ?
Do you think this need a RFC? I can write some
Martin Scotta
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 likeforeach($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-scopeand 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 afterwardsand/or maybe
- allowing to explicitly limit variable-scopes inside blocks, for
example by allowing var $found somewhere inside a function to allow
things likeif($a) {
var $temp;$temp = 5;
}
// and $temp would be gone here; was limited to the scope in which it
was defined by varHope 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.
What if the unset is injected at core level ?
Tyrael
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
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 likeforeach($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-scopeand 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 afterwardsand/or maybe
- allowing to explicitly limit variable-scopes inside blocks, for
example by allowing var $found somewhere inside a function to allow
things likeif($a) {
var $temp;$temp = 5;
}
// and $temp would be gone here; was limited to the scope in which it
was defined by varHope 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
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?
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. 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.
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,
Stefan Neufeind
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 likeforeach($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-scopeand 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 afterwardsand/or maybe
- allowing to explicitly limit variable-scopes inside blocks, for
example by allowing var $found somewhere inside a function to allow
things likeif($a) {
var $temp;$temp = 5;
}
// and $temp would be gone here; was limited to the scope in which it
was defined by varHope 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
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...
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?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 somevar $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. 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.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,
Stefan NeufeindHi,
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 likeforeach($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-scopeand 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 afterwardsand/or maybe
- allowing to explicitly limit variable-scopes inside blocks, for
example by allowing var $found somewhere inside a function to allow
things likeif($a) {
var $temp;$temp = 5;
}
// and $temp would be gone here; was limited to the scope in which it
was defined by varHope 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
Martin Scotta
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?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 somevar $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. 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.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,
Stefan NeufeindOn 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
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 likeforeach($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-scopeand 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 afterwardsand/or maybe
- allowing to explicitly limit variable-scopes inside blocks, for
example by allowing var $found somewhere inside a function to
allow
things likeif($a) {
var $temp;$temp = 5;
}
// and $temp would be gone here; was limited to the scope in which it
was defined by varHope 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
foreach ($values as $value) {
// use $value
}
unset ($value); // <-- unset done inside core
foreach ($values as $key => $value) {
// use $key and $value
}
unset ($key, $value); // <-- unset done inside core
will this just do the trick?
Hello,
Martin Scotta
foreach ($values as $value) {
// use $value
}
unset ($value); // <-- unset done inside coreforeach ($values as $key => $value) {
// use $key and $value
}
unset ($key, $value); // <-- unset done inside corewill this just do the trick?
I think proposed change is extremely counter intuitive to the design
of PHP in regard to scoping and would be a very large bc break, PHP is
doing exactly what it is suppose to do here and I wouldn't want it any
other way.
-Chris
Martin Scotta
foreach ($values as $value) {
// use $value
}
unset ($value); // <-- unset done inside coreforeach ($values as $key => $value) {
// use $key and $value
}
unset ($key, $value); // <-- unset done inside corewill this just do the trick?
I think proposed change is extremely counter intuitive to the design
of PHP in regard to scoping and would be a very large bc break, PHP is
doing exactly what it is suppose to do here and I wouldn't want it any
other way.
I totally agree.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
I think proposed change is extremely counter intuitive to the design
of PHP in regard to scoping and would be a very large bc break, PHP is
doing exactly what it is suppose to do here and I wouldn't want it any
other way.
Agreed. Although I generally favor the idea of strong scope, it isn't practical to implement in PHP. It isn't sensible because PHP doesn't require explicit variable declaration, and the BC break would be crippling.
John Crenshaw
Priacta, Inc.
I think proposed change is extremely counter intuitive to the design
of PHP in regard to scoping and would be a very large bc break, PHP is
doing exactly what it is suppose to do here and I wouldn't want it any
other way.
Agreed. Although I generally favor the idea of strong scope, it isn't
practical to implement in PHP. It isn't sensible because PHP doesn't
require explicit variable declaration, and the BC break would be crippling.
So what about modifying the loop syntax slightly, to explicitly scope a
variable in a foreach? Or would this be problematic/counter-intuitive too?
foreach ($abc as var $def) {
}
and
foreach ($abc as var &$def) {
}
Dave
So what about modifying the loop syntax slightly, to explicitly scope a
variable in a foreach? Or would this be problematic/counter-intuitive too?foreach ($abc as var $def) {
}and
foreach ($abc as var &$def) {
}
PHP's scoping behaviour — particularly around foreach loops and
references — confuses the hell out of people already. I don't think
adding another optional mode that's triggered by a keyword is going to
make that any less confusing, frankly.
Adam
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
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.
I do, and I've seen the construct used many times. It would be a major
pain to track down and fix if this behaviour changes.
Cheers,
David