- For class objects (obj.HasKey("__Class")), return "Class", mainly because it would seem semantically incorrect/misleading to return the class name (or the base class name).
- For instances of a class, return obj.base.__Class (the class name).
- For COM objects, it seems appropriate to return different type names depending on the variant type, since it affects which methods and properties the object supports:
- For VT_ARRAY, return "ComObjArray". (Supports array indexing and a few methods.)
- For VT_BYREF, return "ComObjRef". (Supports ref[] and ref[] := value.)
- For VT_DISPATCH or VT_UNKNOWN:
- If the object implements IProvideClassInfo, return the class name.
- Else if the type is VT_DISPATCH, return "ComObject".
- Else return "ComObjValue".
I considered "ComObjVariant" rather than "ComObjValue", but it's really not a VARIANT (it just has common properties: a variant type and value), and its value can't be changed. So it basically just represents that one value for its entire lifetime. I chose not to use "ComObjParameter" or similar (based on function names used in v1) because it's not always passed as a parameter, and that function doesn't exist in v2.
The other built-in object types would be:
File (was FileObject)
Func
BoundFunc
RegExMatch (was RegExMatchObject)
Object.Enumerator (was Object::Enumerator)
ComObject.Enumerator (was ComEnum)
ComObjArray.Enumerator (was ComArrayEnum)
Gui (was GuiType)
GuiText, GuiEdit, GuiButton, etc. (because several control types have additional methods).
(In the current build the name is automatically derived from the object's C++ class name.)
These type names would also be displayed in ListVars and returned to the (DBGp) debugger. (DebugVars.ahk is already designed to display it.)