Legacy mode

[mansellan]

Is your feature request related to a problem? It should be possible to specify that a given twinBASIC project only allows legacy syntax.

Describe the solution you'd like A project-level switch that disallows any syntax that would not be valid in legacy VB6.

Additional context twinBASIC includes superb language extensions, for example generics and overloads. However, use of these renders source code incompatible with the legacy VB6 compiler. It should be possible to specify a project as "legacy mode", whereby the compiler only allows legacy-compatible syntax.

[bclothier]

FWIW, I wouldn't want it to be only a project-level switch. Imagine that I've inherited a old codebase and I am asked to add new feature. I probably want to enable it as I go through the codebase, maybe on a per-file level or per-namespace level, allowing me to amortize the tech debt payments.

That is a slightly different scenario than supporting compatibility with VB6 users but something to consider.

[WaynePhillipsEA]

I agree, this should probably be an option per file/component as well, much like how Option Explicit is currently handled.

[Kr00l]

Will this mode be an on - off switch, or a drop-down choice? I would imagine a drop-down as following.. Legacy mode:

• none (default, full feature set)
• VB6/VBA6
• VBA7 (allowing LongLong, LongPtr, 64 bit etc.)

[Kr00l]

When legacy mode is on, will then twinbasic/twinbasic#61 do default to HKLM instead of HKCU?

[WaynePhillipsEA]

@Kr00l Yes, I expect we'll have to do that.

[mansellan]

Just had a wacky idea. It may be nuts, hence not opening a new issue just yet...

How about a project option, available only in legacy-mode projects, for users who have VB6 installed, to send compilation to the actual VB6 compiler?

It would be a strange thing to do, for sure. But if someone is wedded to the legacy compiler (perhaps they want p-code?), they could get all the modern conveniences of VSCode but still compile exactly as before. Of course, it wouldn't be debuggable in VSC from that form, so probably only of use as a final stage after debugging with tB.

Am I insane?

[WaynePhillipsEA]

Am I insane?

Yes, yes you are. 😜

[mansellan]

Am I insane?

Yes, yes you are. 😜

Good, thanks for confirming :-)

[WaynePhillipsEA]

Don't worry, you're in good company here.

[DaveInCaz]

One use case is editing a shared file that needs to retain compile-ability both in VB6 and also in tB. This couldn't be done with a file-level Option Legacy because (ironically) that would not be backwards compatible. It would have to be project level or something else.

[bclothier]

Just to float a possible suggestion.... is it easier to solve if it was made as a build target? We have win32 and win64; if we then create a new build target, let's call it "vb6" that would follow the VB6's grammar strictly and treat any VBA7 and tB extensions as incompatible.

By using build configuration instead of a project configuration, we can make it easier to make explicit the intended audience as discussed in twinbasic/twinbasic#16 and hopefully encourage a better separation. If I'm upgrading a large project, I probably will want to have my new code in a new project that the original project can reference safely via compatible interfaces.

[mwolfe02]

is it easier to solve if it was made as a build target?

Interesting thought. Especially as it relates to package management. Is part of this idea that it would better support a potential ecosystem of tB packages that target VB6? In some ways, this could become a de facto VB6 package manager, as nothing like that really exists now (correct?).

[DaveInCaz]

I think the developer should make an explicit choice in some way to decide to "upgrade" the project from standard VB6/VBA to newer tB features. I can see that one important use case would be for maintenance of older projects - you may want to use tB just because the toolset is so much better, but you only want to make minimal changes to the code itself. You don't want tB features to "creep in" unintentionally because that would broaden your regression testing work.

[bclothier]

FWIW, this side comment came up in the discussion from #38. Quoting here for further discussion.

I'm not sure how I feel about the idea of having the file extension enabling/disabling the language features.

@bclothier Agreed I'd rather not, but it's also sort of my suggestion for implicit namespaces; public code in .bas files goes into the global namespace but public code in Modules defined in .twin files is contained in a namespace for that file to add better encapsulation.

It means we can 100% guarantee an easy migration to tB with all edge cases, and then moving to .twin files can sidestep some small fraction of edge cases where the value is massive and the likelihood of this affecting any real code is minimal

[DaveInCaz]

VB6 is very file-oriented in certain ways...

• 1 Class = 1 file
• Modules have implicit file scope for private members

etc.

For VBx programmers coming to tB I think basing legacy features on the file type is actually an intuitive and elegant approach. Renaming your VB files to tB would be a very explicit, opt-in action that I think would be easy to understand.

Especially if there is an IDE refactoring which could do this for you (rename file + any other necessary code updates?) in one go it might also be relatively painless.