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

[John Anderson]

On 5/29/2021 3:50 PM, Christof Thalhofer wrote:
> Am 29.05.21 um 22:09 schrieb Benoît Minisini:
>
>> So maybe I could allow declaring "static variables" (actually private
>> global class variables) inside functions in the future.
> That would make code even uglier. Is there any reason to do this that
> makes sense?
>
> Alles Gute
>
> Christof Thalhofer
>

Thanks, I understand your concern...and it is not my intention that my 
needs require Gamabs to break anything it currently does well.

Let me explain the situation more.  Warning - this is long, but only way 
I know of to explain.  If your time is short please just skip the rest. 
The following ONLY applies to VB conversion project.

Well, in order to implement the equivalent of a "Static" var in a 
function, and since a lot of our functions use common names as 
"mystaticvar" in lots of functions: the only way I know of is to make a 
separate module for each function.

So we go from a dozen or so module files on VB side to over a 1000 
modules on Gambas side...just to deal with the fact Gambas doesn't 
support static var type define inside a function.  And we don't even 
know if Gambas scales that way.

Static might not seem "pretty" to you, but you don't have to use it in 
your code if you don't want to.  For those of us working on an existing 
conversion project:  Having a way to use as much tested / working VBcode 
as possible would be a big plus.  Pretty?  Probably not by your 
standard.  But easily upgrading VB6 code to Gambas is really "pretty" to 
me, and a lot of VB programmers might agree. Time = Money.

Gambas is SOOO close to working with VB code as-is too.   Then I get 
into details and it's like I'm seeing a mirage on a desert of 
not-a-lot-of-solutions.  That doesn't mean Gambas isn't really great - 
it is!!

No, you can't always blindly do global "find and replace" on modules 
that contain more than one function that have same static var names 
inside function.  You can wind up with functions sharing vars that are 
supposed to have scope of only one function at a time, and that would be 
disaster.

Good point about "With Globals.mod".  That can work.

Beniot keeps pointing out to not use Structs except for C calls, so that 
tells me there is something to really worry about there, and I need to 
do more testing.  Our structs can be a flat 1440 X 1280 32 bit image 
frame data along with several hundred INT32 and INT64, lots of 64 bit 
"Doubles" (VB / C term), fixed length strings, byte arrays etc.  And 
then those structs are contained arrays themselves.  So we might be 
passing around a memory pointer to many 10's or 100 MB of data at a time 
that has to work with Gambas  and C.  I know Gambas would rather have 
Structs be setup  in it's own class object format, but we need 
everything to be portable to C with a single pointer.  Maybe these big 
structs will slow down Gambas too much.

The bottom line is on Tuesday morning I have to go into the boss and 
tell him Gambas looked really good initially...but it is just enough 
different that the time required  to convert working code is now going 
to take X amount of time longer because we need to redesign the module 
layout because Gambas doesn't have a way to declare a static var or 
array in a function.  Then he'll say "How does this make the final 
product any different?"...and I'll say "It doesn't"...and then he'll say 
"Screw that".... and so on.  OK. That's not anyone's fault, it is what 
it is.  Maybe we can't use Gambas after all...if we have to redesign 
from scratch it might as well go to Qt where we don't have to worry 
about structs being C compatible  - but Qt is going closed source these 
days.  Dang. There's goofy Xojo but...it has issues too.

In the industrial world we like to get everything working and vetted one 
time - because on a semicon fab line it can cost millions of dollars 
testing time over several months before the machine is turned loose to 
run really expensive product.  One wafer of devices is worth upwards for 
USD$250k, and the machine must not break or stop for any reason while 
processing.  So we have to do a lot of in-house testing and do our best 
to break code ahead of time, and build in lots of safety checks.  Once 
the product is in the field we try not to ever change it - because 
changing a single line of code could trigger a customer on-site test 
cycle again and that costs lots of time & money.   Think Big and Think 
Big Giverment DoD contractors, and think of all the rules that are in 
place if we have to do a software update.

We don't even make an GUI installer package for customers - we send them 
a whole disk image ready to setup from thumb drive or just physical 
SSD.  On Windows that's done with WES7 (Like Win7 but licensed across a 
fleet of machines, and still current for a few more years to industrial 
users), and on Linux we just send a disk all ready to go.  In any case 
customer plugs in disk, it boots and system runs fine on any hardware we 
have in the field.   No install dependencies to worry about because 
we've set everything up on the disk image, and that's how it'll be for a 
long time.

After the system is running, we probably won't update anything for 
decades, nor would we want to.  These machines are not on the 'Net, and 
they have only two jobs to do:  Run, and Run Faster.  Forever. No matter 
how the source code looks.

Assuming that big C-friendly Structs could be used in Gambas (If not we 
couldn't eevn use Gambas):

What would be really cool is a gb.VBConversion component that could (and 
we'd happily pay for this on a commercial project if it saves testing 
time and errors):

1. Support "static" var.  Gamabas already let's you Dim a var inside a 
function, a Static seems reasonable.  You don't have to use it if you 
don't want to.

2.  Support "End Function, End Sub" etc without complaining. Gambas can 
also know that "Type" is a "Struct" and so on.  Those are minor little 
things I know.  Just saving some steps will not hurt anything.

3.  "Double" is 8 bytes in VB and C world, it would seem a small thing 
to have Gambas know that a "Double" is same as "gb.Float" type also.   
It's confusing reading Gambas code because in C world a "Float" is 4 
bytes - which we never ever use anyway, and we never once used a VB Single.

4.  With this gb.VBConversion, arrays could be delimited with "()" 
instead of just "[]".  Why not make life easier for VB folks to get 
drawn into Gambas World.

5.  If possible, some way to define local or static arrays inside a 
function.  Again, mybe not pretty, but it's what I have to work with on 
a conversion - in many hundreds of functions.

I know I know Gambas is not Basic, but it seems surely inspired by VB in 
a lot of ways.  Having a way to have it embrace legacy VB code a little 
easier (with minimal re-write time) would be REALLY cool, as long as it 
doesn't break any existing projects.

If you were building a new project in Gambas, or working with an 
existing Gambas project:  not any of what I just wrote would be required.

Over 'N Out

-John