Re: scope of variables

new topic     » goto parent     » topic index » view thread      » older message » newer message
ChrisB said...

My vote would be against allowing variable creation within loops(etc).

Chris

This was a design decision made way back when it was decided to allow one to declare a variable anywhere inside a routine.

ChrisB said...

One of the arguments for allowing this 'shadowing' of variables, and creating a new instance of a variable within a while / for (etc) loop was that it allows Euphoria to behave like other languages.

Euphoria is not like other languages. To allow creating another variable within a loop (or other instances within a function / procedure that has already been defined within that function procedure) is simply asking for trouble. Its just not necessary.

I don't believe that existing code will be broken, as this method has never been allowed.

Jeremy has proposed that this be linked to the concept of shadowing a variable in the local file vs a private variable in a routine.

E.g., that this be made illegal:

integer i 
 
function s() 
integer i = 1 
return i 
end function 

He's all-or-nothing on this point (well, AFAICS and IMVHO, with statement option aside).

This is what would break existing code (all the way back to 1.x).

This actually raises a counter argument. Euphoria already had this feature. We've had shadowing all the way back since the 1.0 days of Euphoria, yet never had a problem before. Jeremy is saying that allowing shadowing in the new scopes can cause all sorts of bugs - but is there an Euphoria example from the past that demonstrates this?

If not, then why assume that it would cause a problem with the new scopes?

I think comparision with PHP (which does things like scoping quite differently than Euphoria, or C for that matter) is less valid than an Euphoric example.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu