Martin Scotta
On Thu, Jun 23, 2011 at 12:27 PM, Stefan Neufeind <neufe...@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. 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
>
> > 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
> >>
> >
>
>
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?
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
