A variable accessable only in the scope of includefile

[Kurzer]

I have no idea if this request is completely stupid or if one can achieve the behaviour using another way, but...

... is it possible to limit the scope of a "global" variable only to the sourcefile where the varable was defined?
I think about a kind of "Protected" keyword which limit the variable scope to a single procedure, but with a wider scope to the whole file.

The reason for this is: For specific jobs I use a singe includefile, which contains all the prodecures I need for the job.
E.g. serialport communication or an include for a special custom control... The used variables and structures in this includefiles are absoluteley insignificant for the main sourcecode. So I want to shield them from the rest of the programcode.

Maybe a new keyword could do this job?
We have Protected, Static, Shared and Global - so why not introduce an new one called "Local" or so?

[skywalk]

This is like modules and has been requested.
One way to reduce global exposures(and you should anyway) is to embed your variables in Structures and define them within an Init() procedure.

[Little John]

... is it possible to limit the scope of a "global" variable only to the sourcefile where the varable was defined?

(This has been frequently requested before, BTW)

+1

Regards, Little John

[Shield]

For further reference, check this thread out:
http://www.purebasic.fr/english/viewtop ... =3&t=16224

[jassing]

Then, just tossing it out there, if you have a variable that is scoped to just the include file, what about a global var that is scoped to just the include file...

Personally, I think this could lead to some really sloppy and difficult code to read...

[Kurzer]

Hello Jassing,
I am not sure if I understand you fully.

In my opinion there is no difference to a "Global var <-> Protected var" comparsion.
A protected variable is only valid within a procedure (where it was defined as protected) and a global variable is everywhere valid, also within the procedure. But the protected variable is not valid outside the procedure. This is how it allready works now.

Now change the word "proteceted" to "local" and the word "procedure" to "includefile".
What is the difference (except the wider scope of the local variable)?

I don't think this feature would lead into difficulties. Maybe the IDE could be enhanced to define different highligning colors for the various variable scope types. So every global, protected, static ect.. variable could be highlighted in a own color.

[MachineCode]

The reason for this is: For specific jobs I use a singe includefile, which contains all the prodecures I need for the job.
E.g. serialport communication or an include for a special custom control... The used variables and structures in this includefiles are absoluteley insignificant for the main sourcecode. So I want to shield them from the rest of the programcode.

Hang on... a global variable will only be used when used. So if your procedures in that IncludeFile are calling it, then the rest of your app won't care that it exists. What's the problem?

[Tenaja]

It can be a problem if (for instance) you are creating a library, and some local "global variable" name gets used in either the main program or yet another library.

It can also be helpful to make sure your file-specific global variable name is not accidentally used in a proc in the main code without declaring the var name. With the current features, EnableExplicit would not help you, but with this feature implemented, you would get that "undefined" error.

I have seen something similar done in other compilers with the filename preceding the var with a "." separator:
MyIncFile.FileGlobal = 3 ; The first half is only used outside of the include file.

[ozzie]

+1 because I had this feature in VB6.

When I converted my VB6 app to PB I took my file-specific variables and placed them in structures, one structure for each affected file, and then created global variables using those structures. It made the code a bit messy, so this PB Feature Request could help new users coming from VB6 (and possibly from some other languages).

[Tenaja]

+1 because I had this feature in VB6.

When I converted my VB6 app to PB I took my file-specific variables and placed them in structures, one structure for each affected file, and then created global variables using those structures. It made the code a bit messy, so this PB Feature Request could help new users coming from VB6 (and possibly from some other languages).

that's a great idea for a compromise....in fact, you could make 'local' macros that extend the structure...
and, Fred would have a lot less work if he implemented it that way.