Re: scope of variables
- Posted by jaygade Dec 30, 2010
- 2846 views
I think that it should be changed. The current behavior is inconsistent with other languages and unintuitive. One would expect a block started by a loop or an decision block to work the same as a block defined by a procedure or function.
Changed in what way? There are two possible options here:
integer a = 10 procedure abc() integer a = 20 -- INVALID, a already exists in a containing scope end procedure
and the other change is to make all scopes work like this
integer a = 10 procedure abc() integer a = 20 ? a end procedure -- procedure output is 20
The second, of course.
We have to think carefully about this. I'll ask my question again since it seems to be ignored, what is a valid use of redefining a variable in a more narrow scope? In the directly above synario you have now cut off all possibility of accessing the file wide a. Why would you want to do that? Bearing in mind that in a real application there would not be a file wide variable named a, it would be something useful such with a useful name.
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.
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.
For me it seems much more prudent that if there were to be a change the change to be never to allow a variable inside the same namespace to be redeclared. One may say it's heresy, but please tell me why and give valid examples as to how it is necessary to redefine a variable in a more narrow scope to mean something totally different than what it means in a file wide scope.
Jeremy
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.
Anyway, it's not a feature that I will use. I just think that it should be consistent. That's my reason for my vote.
