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 notices 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: I do not have a white paper handy. 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 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 symbol 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 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
- 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 where object or variant was before. And, last but not least, when warranted by a specific situation, we make changes to the core translation engine or we implement custom type-inference algorithms in Migration DLLs or gmSL scripts.