Versions Compared

Old Version 2

changes.mady.by.user George Juras

Saved on

compared with

New Version 3

changes.mady.by.user Mark Juras

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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:  I do not have a white paper handy.  In  

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 symbol 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
  • 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.

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.