Tweet
this is a follow-up of one of the topics contained in a previous thread ( http://www.powerbasic.com/support/pb...read.php?t=347 ).
lance had answered:
this is right. myvar is dimmed as shared at module level, so it exists inside the sub too, then inside the sub a local or another scope descriptor must be needed in order to create another var with the same name but with different scope.
however, if i don' t use local, the duplicate name definition error is not what happens, it is what should happen imo. what happens is that the shared attribute seems to be given to the var. anyway it becomes the same var of module level. i think the original post was asking about this.
even though this is not my problem, this seems me incompatible with reference guide pag. 267 stating that
so i was expecting not to be necessary to repeat local in the dims inside the sub, since it should be the default.
but it' s just matter of interpretation and of manuals printing, it can' t be a real problem for anybody, except maybe for some initial confusion. however just type local in the dims (it is more readable too) and go. probably this is not even necessary if you explicitly put local in the sub header.
the new var will be local to the sub and will hide the shared one with the same name dimmed at module level. as long as the execution stays in the sub, myvar is the one dimmed in the sub, not the one dimmed as shared at module level.
so far it' s all clear, now my question comes. i always found not so easy having a global and complete vision on all the aspects of vars scopes, so i' m probably missing some of them, but i can' t realize which one. i hope somebody can help me in figuring this out since i believe scopes separation is a very important way to easy maintainance.
if i don' t use local in the sub, the compiler assumes that i' m just redeclaring the same variable, but i should not be allowed to dim twice the same var. if i can, then it' s not the same var. but it is.
if you redeclare the same var within a scope where a var with the same name already exists, you can expect a healthy 466 duplicate name definition error, and you' ll get it. dimming the same scalar var twice should be a big no-no in pb/dos, afaik.
the only way i' d expect this sub' s var to be [mis?]taken for the one at module level, is if i write
in the sub.
and if i do so, it works exactely like it works if i don' t put anything, as if the default scope for the sub' s dim was shared .
hey, this is just for understanding, just to see if i' m sleeping on something hidden (from me).
i got no scopes issues here. if you want local vars in the sub, just dim them as local (as dim entry clearly states in the docs).
------------------
lance had answered:
1. the duplicate variable error will not occur if you include the word local in the dim statement in the sub... otherwise the compiler assumes that you are just redeclaring the same variable... ie:
Code:
$dim all
dim myvar as shared integer
myvar = 1
call mysub()
print myvar
sub mysub()
dim myvar as local integer
myvar = -1
end sub
however, if i don' t use local, the duplicate name definition error is not what happens, it is what should happen imo. what happens is that the shared attribute seems to be given to the var. anyway it becomes the same var of module level. i think the original post was asking about this.
even though this is not my problem, this seems me incompatible with reference guide pag. 267 stating that
"the default variable type within the sub body can be specified by including a type class keyword (static, shared, or local) at the end of the header; the default, if no keyword is included, is local".
but it' s just matter of interpretation and of manuals printing, it can' t be a real problem for anybody, except maybe for some initial confusion. however just type local in the dims (it is more readable too) and go. probably this is not even necessary if you explicitly put local in the sub header.
the new var will be local to the sub and will hide the shared one with the same name dimmed at module level. as long as the execution stays in the sub, myvar is the one dimmed in the sub, not the one dimmed as shared at module level.
so far it' s all clear, now my question comes. i always found not so easy having a global and complete vision on all the aspects of vars scopes, so i' m probably missing some of them, but i can' t realize which one. i hope somebody can help me in figuring this out since i believe scopes separation is a very important way to easy maintainance.
if i don' t use local in the sub, the compiler assumes that i' m just redeclaring the same variable, but i should not be allowed to dim twice the same var. if i can, then it' s not the same var. but it is.
if you redeclare the same var within a scope where a var with the same name already exists, you can expect a healthy 466 duplicate name definition error, and you' ll get it. dimming the same scalar var twice should be a big no-no in pb/dos, afaik.
the only way i' d expect this sub' s var to be [mis?]taken for the one at module level, is if i write
Code:
dim myvar as [b] shared [b] integer
and if i do so, it works exactely like it works if i don' t put anything, as if the default scope for the sub' s dim was shared .
hey, this is just for understanding, just to see if i' m sleeping on something hidden (from me).
i got no scopes issues here. if you want local vars in the sub, just dim them as local (as dim entry clearly states in the docs).
------------------
Comment