GLBasic forum

Hi,

there was a discussion about automatically generated variables like:

FUNCTION foo:
  bar = 5
ENDFUNCTION


What scope do you want these variables to be.

Hmmm, wenn die Variablen nun Automatisch gesetzt werden, dann greift ja in der IDE das "Expliziete Deklaration" nicht mehr,
oder?

I voted for "global in main, local in functions" as that is kind of the most expected option. But definitely local inside functions.

I think GLOBAL for main, LOCAL for SUBs/FUNCs would be the way to go..

Ich finde der Explizite Deklarationen sollte Standard werden. JEDE ordentliche Programmiersprache (auch viele BASIC Dialekte) sind in diesem "Modus" (PHP zählt für mich nicht als ordentliche Programmiersprache ;D). Dadurch entstehen einfach viel weniger Fehler und ist somit einfacher zu warten.

Quote from: MrTAToad on 2010-May-18
I think GLOBAL for main, LOCAL for SUBs/FUNCs would be the way to go..

*SIGN*

I too preffer local in function, global outside functions since this will cause least problems if you forget to turn on (or don't know it exists) Explicit declarations.

Please make explicit declarations standard since most newbie errors I have seen in GLBasic could have been avoided if this was on :-)

Uh-Oh!
When you have this code:


FUNCTION foo:
   bar = 5
ENDFUNCTION

// new file e.g.
GLOBAL bar


The bar variable must either be created as a local here or must be known to be a global at that point - or later. The problem is, that at that point I don't know if it's local or global, yet.
How would I take care of that?
2-pass compiling? That would duplicate the compile time. Also it's a very lot of work. :/

You can access a global var of the same name by addressing:
PRINT GLOBAL bar, 0,0

but, in this case you might want to access a global variable within a function, of which the compiler currently has no knowledge. Thus, it would auto create a LOCAL for that. It might not be what you want.

You get warnings about auto-created variables, though.

I'm not in favour of twice the compile time
The most logical is what everyone else suggested - local in funcs/subs, global outside that.

This probably won't be a popular suggestion but what about just forcing explicit variables? I like implicit variables for quick 1 function prototyping, but I turn on explicit for my projects. I wouldn't be too upset to see implicit variables removed (though I understand people porting code won't share that opinion! :D )

With your example code Gernot, even if you did do 2-pass compiling you still have a problem in that the code is ambiguous.  The "Bar" variable referenced in the function could easily be local or global - both are correct.

An alternate idea : create the bar variable in the Function as Local, the bar in the main section as global, display at compile time "warning : variable implicitly created" then if any variables were implicitly created during the compile stage display another error at the end of the linking process saying something like "Warning : implicit variables have been created and may cause unexpected program behaviour".

Worst case create all implicit variables as global?

if anyone of these faster as the other method ?
if so i prefer this. :D

IMO variables should always be defined explicity nowadays. Implicit varaible generation can produce undesired effects, in example, when you mistake to write the variable name, and you only receive the message when compiling in DEBUG mode.

I think it is better that programmer could have total control over variables so compiler should not create them by its own.

But that kind of goes against philosophy of BASIC language. The whole point is to enable beginners to write quick and dirty programs that work, regardless of variable declarations or whatnot.

The problem is that if the beginner misspells a variable name, the program will break in non-obvious ways and the user spends several days trying to figure out what is wrong.