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

[John Anderson]

On 5/29/2021 1:09 PM, Benoît Minisini wrote:
> Le 29/05/2021 à 21:25, John Anderson a écrit :
>> On converting larger codebase from VB6 to Gambas,  I wanted to double 
>> check my method for converting "static" type variable module declares 
>> into the Gambas way. This might be obvious to everyone, but I just 
>> wanted to be sure.  Or am I smoking the wrong stuff again?
>> [...]
>
> I didn't allow to declare static class variable inside functions, like 
> you can do in C (and other languages).
>
> I think it's mainly for the same reason I prevented declaring local 
> variables anywhere in the code.
>
> After some pressure from people I won't give the names, I accepted to 
> allow local variable declaration anywhere.
>
> Now I regret. It makes the code so ugly for me! :-)
>
> So maybe I could allow declaring "static variables" (actually private 
> global class variables) inside functions in the future.
>
> In the meantime, you have to use the wokraround you described. 
> Something like that:
>
> Public Sub MyFunction()
>
>   Private (or 'Static' or something else?) somevar As String = "first"
>
>   ...
>
> End
>
> becomes:
>
> Static Private MyFunction_somevar As String = "first"
>
> Public Sub MyFunction()
>
>   ...
>
> End
>
> One question remains: does the "static" 'somevar' be actually static 
> or not? I.e. is there only one 'somevar' variable for all the process, 
> or one 'somevar' variable for each object of the class. How to make 
> the difference?
>
>>
>> 'Gambas module file
>>
>> 'Static-like vars declared here
>> Private myLVar As Long = 0
>> Private myArray[20, 500] As Integer
>
> One remark about that last line: don't do that.
>
> Don't use the syntax myArray[20, 500], because it creates an embedded 
> array which is a special beast that is mainly useful for interfacing 
> with C code.
>
> Use a "normal" array instead (which is a standard Gambas object):
>
> Private myArray As New Integer[20, 500]
>
> Regards,
>
Thanks Benoît,

Well here's the thing...We don't care much about Gambas-type objects on 
this project, because 95% of what we're doing IS working directly with 
C-Code. So if an object is not C-friendly, it has no use for us.   We 
don't care what the source code looks like, as long as it works exactly 
the same way the VB6 code has been running since 1998 (i.e. millions of 
machine hours testing, running 24/7) - and what you've done with Gambas 
is a really good superVB, Benoît !!  Love that J-I-T stuff for the 
elaborate code-math sections!!  That also works good on some XML 
configuration files we have to read in. Neat!  That is a HUGE upgrade 
for us right there.

Right now, my Sorta-Kinda-Automated VB6 to Gambas Converted Build helper 
is being tested to work like this - Because I ain't manually converting 
84,000 lines of code from VB6 to Gambas when -MOST EVERYTHING- can stay 
the same...Obviously ON ERROR sections will have to get tweaked, but 
doing the following can automate a lot of conversion from VB world and 
bridge to Gambas:

This is  VERY rough FIRST DRAFT I'm testing on some smaller projects - 
having a way to declare a variable as type static would really help a 
lot for doing VB6 to Gambas conversion - but it is not entirely 
required.  Just more work if we don't have it:

1.  First we scan the entire VB6 project files and look for global vars 
and move those declares into Gambas module "Globals.mod". Yes we have a 
lot of them and No I won't get into a religious argument as to why they 
are there.  This is a GUI for a semiconductor fab machine on an assembly 
line, and you learn in a hurry why you sometimes need global vars when 
you have to work fast with C-code threads for coordinating machine 
motors controls, machine vision, and handling operator command inputs, 
configuration setups, spewing out performance reports and test data for 
the next machine on the assembly line.  "This is where theory ends and 
reality begins", as the sign on my lab says.  If you can keep the system 
design so all you do is pass a data struct memory pointer form one piece 
of code to the next, you're good.  And no weird ways of storing 
variables...Large Structs and arrays of Structs all have to pass back 
and forth to C without any extra conversion steps.  Passing single 
pointer should do it in most cases.

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.

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.

3.  Now I have to go thru all the VB6 modules and pull out every Sub / 
Function of name myFuncName or mySubName.  Build a new Gambas.mod file 
of name myFuncName or mySubName, and paste existing VB6 code just for 
the that -one- procedure into the .mod file.

NOTE:  Each new Gambas Mod file will have only one converted 
Sub/Function from VB6 code.

4.  In the new Mod file, look for any static vars, and place those at 
the top, outside of the procedure call, as Private Static.  Or just 
Private, not sure if you also need to use Static also in a module 
declaration section?

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.

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.

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.

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.

Thanks again!

-John