Auto vs. Variant, when to use Auto?

General
81

The general concept of the auto data type is good and the right way. Using introspection to determine type information
is no problem but in terms of performance it could be tweaked a bit.

82

It would be great if that was built in. The Variant data type had a good and a bad side:

The good was that you could query it for the data type it was holding in a fast way.

The bad that you were able to assign the value to whatever data type you wanted (causing hard to find bugs due to having no compile time checks).

Unfortunately Xojo now leaves the good part of Variant up to you too. I created a module called “Auto” with extension methods to exactly mimic the Variant Type method and the TypeInteger, TypeBoolean, etc. constants. But used in loops it shows to be a lot slower than Variant’s Type method.

83

[quote=207498:@Eli Ott]It would be great if that was built in. The Variant data type had a good and a bad side:

The good was that you could query it for the data type it was holding in a fast way.

The bad that you were able to assign the value to whatever data type you wanted (causing hard to find bugs due to having no compile time checks).

Unfortunately Xojo now leaves the good part of Variant up to you too. I created a module called “Auto” with extension methods to exactly mimic the Variant Type method and the TypeInteger, TypeBoolean, etc. constants. But used in loops it shows to be a lot slower than Variant’s Type method.[/quote]

To be honest I don’t see it built in but let’s see what the future brings…

84

The eventual idea will be that you will be able to do something like:

Select Case Xojo.Introspection.GetType(myAuto) Case GetTypeInfo(Integer) // stuff Case GetTypeInfo(Text) // other stuff End Select

85

It is slow (it involves string comparison).
It is error-prone.
Each developer has to re-invent the wheel.

[code] Dim typeInfo As TypeInfo = GetType(value)

If typeInfo Is Nil Then
// Nil

ElseIf typeInfo.IsPrimitive Then
Select Case typeInfo.Name
Case “Boolean”
// Boolean
Case “Color”
// Color
Case “Int8”, “Int16”, “Int32”, “UInt8”, “UInt16”, “UInt32”
// Integer
Case “Int64”, “UInt64”
// Long
Case “Single”
// Single
Case “Double”
// Double
Case “Currency”
// Currency
Case “Text”
// Text
Case “Ptr”
// Ptr
Case “CString”
// CString
Else
… // TODO
End

ElseIf typeInfo.IsValueType Then
// Structure
// This is just a guess, as there is no TypeInfo.IsStructure property

ElseIf typeInfo.IsClass Then
If typeInfo.Name = “Xojo.Core.Date” Then
// Date
Else
// Object, but not a Xojo.Core.Date
End

ElseIf typeInfo.IsArray Then
Select Case typeInfo.ArrayElementType.Name
Case “Boolean”
// Array of Booleans
Case “Color”
// Array of Colors
…
and so on, you get the picture
…
End

Else
// more?

End[/code]

86

[quote=207523:@Joe Ranieri]The eventual idea will be that you will be able to do something like:

Select Case Xojo.Introspection.GetType(myAuto) Case GetTypeInfo(Integer) // stuff Case GetTypeInfo(Text) // other stuff End Select[/quote]

Wouldn’t it be better if Xojo just did an Auto.Type method then? I mean we could always build an extension method but it seems silly to have the user have to use Xojo.Introspection.GetType for something so key to using Auto.

Select Case myAuto.Type Case GetTypeInfo(Integer)

87

[quote=207523:@Joe Ranieri]The eventual idea will be that you will be able to do something like:

Select Case Xojo.Introspection.GetType(myAuto) Case GetTypeInfo(Integer) // stuff Case GetTypeInfo(Text) // other stuff End Select[/quote]

That’s good so far. I didn’t mean it in any other way.