SUGGESTIONS: local variables same name as imports & easy-global export

[SSH]

See also http://www.adventuregamestudio.co.uk/yabb/index.php?topic=22652.msg277775#msg277775

When I declare a local variable, for example in a module function, it can clash with other modules loaded earlier if their script headers import a variable with the same name. In just about every other language I know, local variables mask out any globals of the same name, so it would be nice if AGS cold do this to. As it is there is no way to protect yourself from this, other than giving local variables inside any mdoule long prefixes, which is a pain.

And I just had an idea that will make life easier: If you could right-click on a variable declaration (or CTRL-SOMETHING) and it would automatically add an export command for that var to the end of the script, and an import to the relevant header file. Now THAT would rock.

[Pumaman]

This was actually a conscious decision not to implement the variable masking, because it leads to accidents and "bug reports" when people don't realise they've declared a local variable with teh same name as a global that they're trying to change. Therefore, I felt the best thing to do was to leave it this way.

[SSH]

but I think that the advent of the script module maybe will swing the balance the other way, in that more bug reports  will occur because of exported variables. Maybe it can be a switch like OO and left-to-right

[Scorpiorus]

Surely depends on how much work it is but having such an option on a per module/script file basic would be cool.

Or even on a per definition basis:


local int x = 10;

Looks neat

[SSH]

Good idea. Or even

my int i=0;

(tell the perl fan)

[Pumaman]

I'm still not convinced. Even if that were done, you'd still get people forgetting that they'd declared a local, and then trying to set a global of the same name and reporting bugs because "the global variable didn't get set with what I told it to".

[Scorpiorus]

But maybe just don't make it officially available -- thus most people would use the current rule as before (ie. can't declare a local variable with the same name as a global one).

And module authors could then explicitly declare such local variables to protect their internal module script code from possible name collisions.

As I see it, we have two module types: those publicly available and private modules those used by game developers to structurize their script code. Private modules shouldn't necesserely have export names decorated with some sort of a prefix (although it would be preferable) as long as the game developer can keep track of them in scope of their game but the problem arises when such modules are placed in the list before public ones. Then if a private module exports something like "myvar" and a public module also use that name for a local variable then the compiler reports an error message and reasonably points to *public* module's internal script.

A workaround would be to make module users move their private modules below public ones because public modules just never depend on private ones but it introduces yet another puzzle in terms of having module users to properly sort the modules in the list which is not always a trivial task.

Another possibility would be to suggest public module authors to prefix each local varible with their module name but that would clutter module script a lot.

Maybe some kind of a compiler directive that would only work for the current file (or maybe for the current function) like allowoverrideglobals.

I understand there are enough features on to-do list that have a way higher priority so I'm just wondering of the possibility itself of introducing something like that in a future versions of AGS.

[Pumaman]

Bear in mind that modules can't access exports from the global script, so you could have a variable "jibble" in the global script and exported, and still use it as a local variable name in a script module.

All you'd need to worry about was clashing exported variable names from script modules -- but generally this problem is small because most of the time functions are exported rather than variables.

I can see why you'd want to have this feature available, especially if lots of variables were being exported with names that were likely to clash. I guess we can see whether this becomes a problem before deciding whether to go ahead with it.

[Scorpiorus]

Bear in mind that modules can't access exports from the global script, so you could have a variable "jibble" in the global script and exported, and still use it as a local variable name in a script module.

All you'd need to worry about was clashing exported variable names from script modules -- but generally this problem is small because most of the time functions are exported rather than variables.

Yeah, that was only a single report so far but seems like people started to use module support feature in their games what is good on its own.

I guess we can see whether this becomes a problem before deciding whether to go ahead with it.

Sure, thanks.

[SSH]

OK, CJ, we'll see if anyone else gets the problem coming up. I think it will occur when someone is writing a module outside the guidelines that Rick and Scorp put together, which i guess means everyone except those two and me

And I just had an idea that will make life easier: If you could right-click on a variable declaration (or CTRL-SOMETHING) and it would automatically add an export command for that var to the end of the script, and an import to the relevant header file. Now THAT would rock.

No-one has commented on this idea, though. Was it THAT bad?

[Scorpiorus]

And I just had an idea that will make life easier: If you could right-click on a variable declaration (or CTRL-SOMETHING) and it would automatically add an export command for that var to the end of the script, and an import to the relevant header file. Now THAT would rock.

No-one has commented on this idea, though. Was it THAT bad?

It's not a bad idea but imho it would be not trivial to implement to work properly. The editor then needs to check if it's already exported/imported which in worst case would require to recompile the script, eg. if its export/import declaration is already there but hidden by some #define, then recompilation may fail because of some other errors in the script. Another question is what place it should put such imports, should it add them at the end of header file, etc...

So it would be handy but considering the fact interface is to be not changed that frequintly I think we can live without it.

[Pumaman]

Yeah, it would be cool for it to do that, but I can't see it happening any time soon, sorry.