SUGGESTION: Export at declaration time

[SSH]

There is redundancy and a bit of hassle in the current system of having the declaration and export of varaibles done separately:

Code: ags

int my_long_variable_name_that_i_might_type_wrong;
export my_long_variable_name_that_i_might_type_wrong;

wouldn't it be possible to add a new mechanism where you can just do:

Code: ags

exporting int my_long_variable_name_that_i_might_type_wrong;

or some other syntax, I'm not fussy 

[Gilbert]

Hehe, or even more lazy:

global int blah;

which saves you from putting the import lines in the header (but then you cannot be sure if some variables are global just by looking at the header).

But of course, keep the old "export" and "import" functionalities unchanged, for compatibilities, and that we sometimes need only the variables accessible in one or two rooms, not all.

[SSH]

global int blah;

which saves you from putting the import lines in the header (but then you cannot be sure if some variables are global just by looking at the header).

But of course, keep the old "export" and "import" functionalities unchanged, for compatibilities, and that we sometimes need only the variables accessible in one or two rooms, not all.

Well, you would change it to ONLY have the import in the header, delteing the export requirement at all rather than the other way around, I think. And yes, this would be in addition to any existing functionality for backward compatibility

[RickJ]

I like the idea of being able to put the export directive on the same line as the declaration.  But is a new directive "exporting" really necessary?  Why not just allow the current one, "export" , to be used in this way in addition to current way?

Code: ags

export int my_long_variable_name_that_i_might_type_wrong;

I don't much mind putting the corresponding import statement in the script header as it gives me control over what I am doing.  Not having to explicitly export variables , as SSH suggests is also acceptable to me.

[Pumaman]

Yes, something like that would be useful, I agree.

[strazer]

Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=544

I like RickJ's suggestion about reusing the export keyword.

[SSH]

or some other syntax, I'm not fussy 

Whatever: I was just trying to make the writing of the parsign code for it easier mfor CJ to do, thus more liekly to get implemented