gmStudio Documentation

Page tree
Skip to end of metadata
Go to start of metadata

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 typically a variable declared As Variant, As Object, As Form, As Control used for for multiple types; also occurs for a variable used as a scalar and an Array
  • using the VB6 CallByName function, 
  • using IF or Select based on TypeName or TypeOf function
  • 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 in the translation process 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)

gmStudio provides an extensive set of upgrade rules and techniques 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.


  • No labels