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

[Brian G]

Regarding creating a separate .mod file for each function and the static variables.
Regarding #pragma suggestion

"Failure is the key to success; 
 each mistake teaches us something"  .. Morihei Ueshiba
Brian G

----- 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(ByVal 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 anywhwere 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 ]----