Re: scope of variables
- Posted by jeremy (admin) Dec 30, 2010
- 2839 views
I don't think there is a valid use. But I don't think there's much of a valid use for block variables anyway outside of the for loop index variable. If you need privately scoped variables you should be using a procedure or function anyway.
This is the main reason why if a change occurs I think it should be the first. Do not allow re-definition of a variable in a child scope, whether that be a procedure, if, for or whatever.
But the feature has been added and it should be consistent with the way that it works in procedures and functions. That is my reason for voting the way I did.
The first solution is making it consistent.
You say you wouldn't have a variable "a" as a file-wide variable. Or even a procedure-wide variable if we're working within a procedure block. And yet, you could. Maybe your file is pretty big and you defined a variable "idx" near the top. You cut and paste a block of code from another program you wrote but end up with a name clash because the block defines its own "idx" variable. Maybe the block is really long too and you don't want to go through and change "idx" to "idy" in every instance.
Contrived? Yes. Bad programming practice? Probably. But other features have been added to 4.0 which enable bad programming practices. Either because they are useful in some small circumstances or because they were requested.
I do not think features were added by mere request. They had to have valid uses. Everything added in 4.0 has a valid use. Everything in programming including a procedure, an if statement and goto can be misused but all have very valid purposes. Re-defining a variable of a different type, cutting off access to higher scope leveled variables I personally do not see a valid reason for. Nor do you it appears. Add it because we can? I don't think that's wise and it has not been the practice thus far w/Euphoria. It shouldn't start to be either.
Obviously quite a few people have not chimed in yet, so I'm sure a lot more discussion to follow!
Jeremy
