[Gambas-user] Type of Variables possible?

[Doriano Blengino]

Kadaitcha Man ha scritto:
> 2009/12/29 Dr. Diesel <dr.diesel at ...626...>:
>
>   
>> just there seems no way to make it
>> global and accessable across different modules/classes.
>>     
>
> HA! I had that same logical problem. There is no concept of global in
> Gabas that matches any variation of VB's idea of global. This is the
> fault of Microsoft. In the old days there was a concept of "global",
> but then OO came along and Microsoft haven't been able to escape the
> problem it created ever since.
>   
Sorry Kadaitcha,

you are confusing scope with visibility and naming, and all these things 
have nothing to do with OO. It seems that everybody in this list talks 
about OO misunderstanding its true meaning. There can be global 
variables in OO, why not? And they are not so bad, anyway - without 
global variables no programs could run...

"Global" is something during the life of the program, like file 
descriptors or static forms. Dynamic data could be thought as "not 
global", but it is anyway because you must have around something to 
access them - and that "something" is global. I mean - in your main form 
there can be some private variables, but they are "global" because your 
form is alive, and it can not live without its data. When the form 
closes, your application closes. During the life of your program, those 
private variables of the main form are always there, so they are global; 
the gambas interpreter, if not you, always know where they are (well, it 
is not exactly so, but near enough).

Visibility is an attribute that define where your identifiers can be 
seen (and used), but this does not necessarily mean that a global 
variable is public. This is the case of private variables in static 
modules: they are global, but invisible outside their defining class. 
There are other visibility attributes not used in gambas, like published 
or protected.
The visibility of a variable can not go out of its scope, of course. So 
a local variable is not global, and can not be public. The scope defines 
the field of existence of a variable, and its visibility attribute can 
restrict its visibility, not its scope; and the visibility attribute can 
not expand the variable scope (or, better, it could: but it would be a 
serious compiler glitch...). Moreover, in other languages you can define 
static local variables, which are global but visible only inside a 
function: a global variable with a very restricted visibility...

Naming is still another issue. Whether a global variable can be accessed 
by "MyGlobalVar" or "MyModule.MyGlobalVar", it is still the same thing: 
that variable is both global and public. Probably the second mechanism 
is better in a modern IDE with automatic completion: it is handy and 
well ordered, but other languages have statements like Import which can 
be used to abbreviate such things. Sometimes I get tired of typing 
blablabla.x1, blablabla.x2 and so on, where a simple "x1" and "x2" would 
signify the same thing.

I don't want to talk about M$ and VB, but I can say something about 
gambas. With great simplicity (sometimes too much simplicity) it brings 
OO programming and good program organization; but this does not mean 
that the gambas way is the only correct one.

To conclude, gambas has global variables (and subroutines); these 
identifiers can be public or private, and you must access them always 
prepending the module name where they are defined. This is a minor 
limitation/simplification, and I can live with it.

Keep in mind the differences between modules, classes, and static classes.

Regards,
Doriano

> You must either pass the object around, as I already mentioned, or you
> reference a module's public properties in this way:
>
> mModuleName.PropertyName = "something"
>
>      where PropertyName is declared as a public string, for example.
>
> Let me try and explain by example. Microsoft tell you not to use
> inline string literals because they slow both the compiler and the
> interpreter down, which is a huge problem for Microsoft because the
> interpreter in .NET 2007 is already slower than a wet week. So, too
> many years ago to remember, I got into the habit of declaring global
> constants for common literals. I have a program here of thousands of
> lines of code that does not use a single literal, and it's still slow.
> Anyway, to the point:
>
> 1) In VB.NET I would declare constants in a single module and in this manner:
>
>     ' Postscript names and values:
>     Public Const QUOTESINGLE As String = "'"
>     Public Const ASTERISK As String = "*"
>     Public Const NUMBERSIGN As String = "#"
>     Public Const PERCENT As String = "%"
>     Public Const PLUS As String = "+"
>     Public Const EQUAL As String = "="
>     [...]
>
> In VB, Public is a euphemism for Global, so I could access any simply
> constant by using it's name, for example:
>
>   If SomeString = EMPTY then...
>
> 2) In Gambas I would declare constants in a single module and in this manner:
>
>     ' Postscript names and values:
>     Public Const QUOTESINGLE As String = "'"
>     Public Const ASTERISK As String = "*"
>     Public Const NUMBERSIGN As String = "#"
>     Public Const PERCENT As String = "%"
>     Public Const PLUS As String = "+"
>     Public Const EQUAL As String = "="
>     [...]
>
> Note the distinct lack of difference?
>
> In Gambas, Public is a euphemism for "exposed to view", so I could
> access any constant by using the form "module.name", for example:
>
>   If SomeString = mConst.EMPTY then...
>
> All of that may seem really weird to you, but the good thing is,
> unlike VB, Gambas forces you to plan your application structure rather
> than VB's "just type code as you go" approach. Personally, this is a
> really good thing.
>
> If you find any of that that difficult to follow, spare a thought for
> me. The uppercase constant names are a fortran 77 convention.
>