twinBASIC Update: June 6, 2021

Mike Wolfe -

On April 23, 2021, I helped Wayne Phillips introduce the world to twinBASIC at the Access DevCon Vienna conference.  I boldly predicted that twinBASIC (along with the Monaco editor) would replace VBA and its outdated development environment by 2025.  With that goal in mind, this weekly update is my attempt to keep the project fresh in the minds of the VBA development community.

Every Sunday, I will be providing updates on the status of the project, linking to new articles discussing twinBASIC, and generally trying to increase engagement with the project.  If you come across items that should be included here, tweet me @NoLongerSet or email me at mike at nolongerset dot com.

Highlights

It was a busy week for bug fixes.  There were 13 new version releases (see Changelog below).  There were 22 issues closed on the GitHub project page.

Mid statement support

In addition to the familiar Mid string function, the VBA language itself has a Mid statement.  Though less commonly used, the Mid statement can be used to boost string handling performance in certain situations.  Support for this feature was added to twinBASIC in version 0.10.717.

DefType statement support

You can use DefType statements to automatically assign a data type to newly declared variables based on the first letter of the variable name.  From the docs:

Used at the module level to set the default data type for variables, arguments passed to procedures, and the return type for Function and Property Get procedures whose names start with the specified characters.

So, yes, you can use DefType statements.  That said, do not use DefType statements in new code.  They are an abomination in 2021.  Instead, explicitly declare the data type of each variable, even if that data type is Variant.

As of version 0.10.800, though, any legacy code that uses DefTypes will now compile and run correctly in twinBASIC.

Various bug fixes

Most of the other new releases were bug fixes of various edge cases.  I've been monitoring the discussion at the GitHub project page and I've been impressed with how quickly Wayne is resolving many of the reported bugs.  For many bugs, the issue is opened and closed within 24 hours.

Around the Web

As the edge cases get edgier, the number of automated tests within the twinBASIC project will continue to rise.  Writing the tests themselves will begin cutting further and further into development time.  With this in mind, Cristian Buse suggested that Wayne might consider opening up the test writing chore directly to the community:

@WaynePhillipsEA  Would it be worth to open up the testing to the community via another repository? So that more is covered with less of your time.

Wayne responded that he was open to the idea, but he wants to wait until he can support unit testing directly within twinBASIC.  Unit testing support is on hold, as Visual Studio Code itself is set to release a new testing API.  Wayne will then leverage VS Code's testing features for twinBASIC's own unit testing implementation.

@cristianbuse yes, I think so.  I would like to see #54 implemented first, so we can start in a formal and structured manner.  I believe the necessary testing features in VS code are due to land in a few days.

To Wayne's point, the relevant VS Code Testing API issue is listed under the June 2021 Milestone for the Visual Studio Code project.  

Here's to hoping unit testing makes an appearance in twinBASIC sometime later this year.

Changelog

Here are the updates from the past week.  You can also find this information by installing the twinBASIC VS Code extension and clicking on the Changelog tab of the extension page:

[v0.10.1088, 6th June 2021]

[v0.10.1076, 5th June 2021]

[v0.10.1066, 5th June 2021]

[v0.10.975, 4th June 2021]

[v0.10.959, 4th June 2021]

[v0.10.951, 4th June 2021]

[v0.10.933, 4th June 2021]

[v0.10.871, 3rd June 2021]

[v0.10.833, 2nd June 2021]

[v0.10.810, 1st June 2021]

[v0.10.800, 1st June 2021]

[v0.10.717, 31st May 2021]

[v0.10.660, 30th May 2021]