> 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 <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
>>>
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
