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

[Christof Thalhofer]

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.

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

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20210530/dfbd4506/attachment.sig>