Kadaitcha Man ha scritto: > 2009/12/29 Dr. Diesel <dr.die...@gmail.com>: > > >> 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. > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user