[Gambas-user] Correct strategy for VB static var conversion to Gambas?

[Brian G]

In previous reply I forgot to remove the byval ref in the example

> Regarding creating a separate .mod file for each function and the static
> variables.
> Regarding #pragma suggestion
> 
> ----- On May 30, 2021, at 10:56 AM, Christof Thalhofer chrisml at deganius.de
> wrote:
> 
>> Am 30.05.21 um 03:00 schrieb John Anderson:
>> 
>>> 1A:  For every variable that was put into Globals.mod, we have go back
>>> through all source code and replace every instance of myglobalvar with
>>> Globals.myglobalvar.  As per Gambas instructions.
>>> 
>>> IDEA>>> This would be cool:  Somewhere at top of Globals.mod, you have
>>> something like #Pragma SET_DEFAULT_MODULE TRUE  Or use whatever keyword
>>> or environment variable you like. This tells Gambas to search this
>>> "Default  Module" for any unknown objects it can't find a reference to
>>> in the rest of the project. Now I don't have to go thru code updating
>>> all the myglobalvar names to Globals.myglobalvar - If Gambas comes to a
>>> var object name it doesn't know, it will just go look in the Default
>>> ModuleName to check there.  In other words give the system a "path" to
>>> look for object declares.
> In Gambas it is possible to use a module and a 'With' Statement
> 
> so moving all globals to a single file
> if you scan your original source using a gambas collection finding all the
> globals
> second pass replace the global symbols with .symbol
> 
> Have you looked at the gambas eval.highlight component?
> 
> eg.
> 
> after moving BoardWidth to the globals.mod module as
> 
> public BoardWidth as float = 0.0
> 
> every other module gets
> 
> 'begin module
> with globals
> 
> 'in all modules replace global symbols with  . as the first character
> 
> .boardwidth = 56.56
> 
> 
> end with
> end module
> 
>> 
>> Very, very ugly, I'm against that!
>> 
>> What you encounter is that the old code of 1998 is a very slippery mess
>> (as it was written back then) and as you have to refactor it for Gambas
>> you now see all the places where it is a mess. If you want to tweak
>> Gambas to be messy because your old code is an ugly piece of mess I'm
>> strictly against that.
>> 
>>> 2.  Now we go thru VB6 sources and change all "Double" type declares to
>>> "Float".  Really ??  Is there any way we can get Double type defined as
>>> the same as Float type? It looks like keyword is available according to
>>> docs, and that would make it easier for us VB / C guys to avoid
>>> mistakes.  But whatever.
>> 
>> Refactor the code. You can search/replace throughout the whole project
>> with one click.
>> 
>>> 5.  In the new Mod file, change the Sub/Func/Procedure name to "F" for
>>> function, or "S" for Sub.  The module file name is already the original
>>> actual procedure name.
>> 
>> Sub / Function is historic, but internally they act the same AFAIK. A
>> Sub in Gambas also can return a value:
>> 
>> Sub Sth as Boolean
>>    Return True
>> End
>> 
> 
Given this example
 
Function updateSales(ByVal thisSale As Decimal) As Decimal
   Static totalSales As Decimal = 0
   totalSales += thisSale
   Return totalSales
 End Function
 
Being called as updateSales(777.77)
 
 If you create a new .mod file for each function/sub that contains static
 variables
 The mode file gets the name of the function/sub. Again in gambas sub/functions
 are just aliases of sub.
 eg
 
 updateSales.mod
 
 Then the code should end up looking like
 
 'begin module
 
 private totalSales as float = 0            ' from decimal
 
 public sub _call(thisSale As float) as float ' from decimal
     totalSales += thisSale
     Return totalSales
 end
 
 'end module
 
 You will not have to change or update the names of your functions/subs anywhere
 else in your code.
 Simply reconstruct it into a module.
 
 _call is a special name in gambas that is executed when a module is called by
 name.
 
 So now your code does not need to change as far as calling the function.
 it still is called as
 
  updateSales(777.77)
 
 I am not sure how many separate modules gambas can support.
> 
> 
> 
>>> 6.  Now loop thru original VB6 sources and look for any occurrence of
>>> "myFuncName" or" mySubName"...and change to "myFuncName.F" or
>>> "mySubName.S"  This was the easiest way I could think of for name the
>>> new module files in the most practical way.
>> 
>> Without giving it much thought, I don't think that's a good idea.
>> 
>>> 7.  Go thru sources and update myArray(..) to myArray[..].  Any VB6
>>> declare of myArray(0 to n) gets converted to a Gambas declare
>>> myArray[n+1].  Etc.
>>> 
>>> And so on.  I'll have to figure out more as I go.  Perhaps Forms will
>>> have to be manually re-constructed to match as much as possible with the
>>> original VB6 form.
>> 
>> Yes.
>> 
>>> This plan might turn out to be an absolute piece of shit when I get to
>>> the bigger project.  But it looks hopeful for at least the code
>>> sections.  Maybe not so much for forms.
>>> 
>>> The concept is that current VB6 code logic works perfectly, and we want
>>> to preserve as much of that as possible without making huge changes -
>>> and as far as the machine operators are concerned they won't see much
>>> change from a Windows to Linux machine.  99.9% of the time they are
>>> looking at the full screen GUI display anyway, and they really don't
>>> interact with the OS on a desktop or terminal level.  As long as they
>>> can run the machine, and maybe open up a Firefox web browser, use PDF
>>> viewer for help files, or get to LibreOffice for looking at report
>>> spreadsheets, that's all they need.  They don't even need to know there
>>> is no "C:" drive anymore.
>> 
>> If you want to convert such an old VB project to Gambas I doubt very
>> much that you can do it in an automatic way. Such old code was often
>> written in a very bad way, so it is full of architectural errors.
>> 
>> This is not "religious", but the bloody experience of many programmers,
>> and it will prevent you from working well with the code in the future.
>> This is called "technical debt".
>> 
>> When refactoring, you come across these errors and instead of blindly
>> accepting them, in my experience it is better to refactor the code right
>> away and use modern concepts which are supported by Gambas. Otherwise,
>> the technical debt has simply been transformed into a new language, but
>> not eliminated.
>> 
>> If you want to ensure that the code does the same as the old one you can
>> at first write tests which test the behavior. After that and together
>> with the usage of Git you can rewrite and refactor the code and
>> eliminate the technical debt. And this in a very free and effective way,
>> as Gambas allows the programmer to do.
>> 
>> Alles Gute
>> 
>> Christof Thalhofer
>> 
>> --
>> Dies ist keine Signatur
>> 
>> 
>> 
>> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----
> 
> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----