View Source

Question:

Is there a white paper or something that explains why some variants are converted to strong types and others are set to object? I noticed in the sample application I have been playing with that not all get set to strong types. I could not find a difference between the one that was set to string the one that was set to object.

Answer:

Type Inference is a critical matter in VB6 translation, even more so for ASP/VBScript, and has has been a central theme in the development of our translation platform. We have also implement custom type-inference algorithms in various extensions and gmSL scripts. Type Inference optimization is an important task in our methodology.

In general the tool favors strong typing, but it backs off to object if it means introducing something that would break the build. There are several possible causes of weak typing:

Explicit use of weak typing
- using one variable for multiple types;
- using the VB6 CallByName function,
- using IF or Select based on TypeName or TypeOf function
- using As Any
- use of variant for dynamic arrays
Weakly typed symbols in a COM API description
Errors in the code that do not show up in VB6 for some reason
Unintended typing variations that are glossed over by VB6 but block unambiguous type inference
Timing issues wherein the type of a symbol is known too late to assist with recognizing code that references the symbol
Depending on a type from a COM API that is not explicitly referenced in the VBP (i.e. CreateObject)
Depending on a type based on a variable expression (i.e. CreateObject)

Having said that, gmStudio provides an extensive set of upgrade configuration tools and techniques that teams may use to improve type inference:

Pre-Edits to change weak declarations to strong ones
Refactor/Fixtype commands to set the type of specific symbols based on fully-qualified identifier
Explicitly referencing a COM description that was not referenced by the VBP (i.e. helps with CreateObject)
Registry type="FixType" to set the type of a class of symbols based on their name
Modifying COM descriptions to set the types of various symbols
Activating the Generic Collections upgrade feature
Adding gmSL routines that help the tool recognize, interpret, and rework specific weak-typing scenarios
Setting a symbol to type="dynamic". But be warned, that does not really solve type inference issues, it merely simplifies late call syntax
Selects that alter type inference behavior at a global level

There are a few more advanced techniques to allow for symbols that are used with multiple-types and even to introduce interfaces or generics where type object or variant was used before.