Auto to Text

I understand that “Auto” was introduced to get rid of implicit type conversion. But the auto type has no methods. What if I want to explicitly turn it into text? With variants you could do something like v.StringValue but there is no equivalent on the Auto type. (WHY NOT?!)

And since there isn’t I’m trying to build a helper method but it seems obnoxious:

[code]Function TextValue(extends a as Auto) As text
Dim info As Xojo.Introspection.TypeInfo = Xojo.Introspection.GetType(a)

#if TargetDesktop or TargetWeb then
if info.Name = “string” then
dim z as String = a
return z.ToText
elseif info.name = “variant” then
dim v as Variant = a
return v.TextValue
end
#endif
Select Case info.Name
Case “Integer”
dim z as integer = a
return z.ToText
Case “Int8”
dim z as Int8 = a
return z.ToText
Case “UInt8”
dim z as UInt8 = a
return z.ToText
Case “UInt16”
dim z as UInt16 = a
return z.ToText
Case “UInt32”
dim z as UInt32 = a
return z.ToText
Case “UInt64”
dim z as UInt64 = a
return z.ToText
Case “Short”
dim z as Short = a
return z.ToText
Case “Byte”
dim z as Byte = a
return z.ToText
Case “Int32”
dim z as int32 = a
return z.ToText
Case “Int64”
dim z as int64 = a
return z.ToText
Case “text”
dim z as text = a
return z
Case “Double”
dim z as Double = a
return z.ToText
Else
return “”
end

End Function

[/code]

I’m I missing something?

You can eliminate the temporary variables by using CType. For example:

Case "Double" return CType(a, Double).ToText

[quote=160386:@Joe Ranieri]You can eliminate the temporary variables by using CType. For example:

Case "Double" return CType(a, Double).ToText [/quote]

Well I cleaned it up:

[code]Function TextValue(extends a as Auto) As text
Dim info As Xojo.Introspection.TypeInfo = Xojo.Introspection.GetType(a)

#if TargetDesktop or TargetWeb then
if info.Name = “string” then
return CType(a, string).totext
elseif info.name = “variant” then
dim v as Variant = a
return v.TextValue
end
#endif
Select Case info.Name
Case “Integer”
return CType(a, Integer).totext
Case “Int8”
return CType(a, Int8).totext
Case “UInt8”
return CType(a, UInt8).totext
Case “UInt16”
return CType(a, UInt16).totext
Case “UInt32”
return CType(a, UInt32).totext
Case “UInt64”
return CType(a, UInt64).totext
Case “Short”
return CType(a, Short).totext
Case “Byte”
return CType(a, Byte).totext
Case “Int32”
return CType(a, Int32).totext
Case “Int64”
return CType(a, Int64).totext
Case “text”
dim t as text = a
return t
Case “Double”
return CType(a, Double).totext
Else
return “”
end

End Function
[/code]

But its still freaking stupid we have to do this.
feedback://showreport?report_id=37800

There is also a feedback case asking for a type property on the auto class.
To avoid all those string comparison and introspection overhead.

[quote=160414:@Christian Schmitz]There is also a feedback case asking for a type property on the auto class.
To avoid all those string comparison and introspection overhead.[/quote]

I do not mind having to cast, but indeed a type property would be nice to have.

A type property probably wont happen as it would tie our hands with respect to plans we have.

That’s fine, but we, the users, are left in the dark as to where Auto is going. What’s the end game in broad strokes?

What plans?

Plans we have for the future.
The ones we dont discuss

Lets put tis this way the use on Introspection to get at the type is deliberate

feedback://showreport?report_id=37710
This case has been closed because it has been decided that this feature will not be implemented.
The lack of a ‘Type’ property on Auto is intentional, as is requiring the use of introspection.

My problem is that I would like to write code to convert between NSDictionary and xojo.core.Dictionary and for that need to check for each key the auto type behind, so I can apply the right conversion code. And using introspection and string compares makes this a very slow procedure for large dictionaries.

The lack of a ‘Type’ property on Auto is intentional, as is requiring the use of introspection.

I’m doing something similar with converting Arrays of Auto into arrays of a primitive. It’s a mess to do…
When the library is done you’ll be able to do something like:

myStrings = myIntegers.toList.toStrings //or even myString = myIntegers.toList.Where("", ">", "5").OrderDescending().toStrings

I figured I should make it work for iOS since it’s a very helpful library. Unfortunately the Auto type is a disaster to work with converting. Adding “Explicit” conversion methods would be very helpful.
:frowning:

I just thought about a quick way of parting between numeric and text without introspection :

[code] dim a as auto
a = 1
dim t as text

Try
T = a
msgbox “Text”
Catch err as TypeMismatchException
msgbox “not text”
end
[/code]

That only works if what you originally put in the Auto was text. And in my case that isn’t always so.

Your method is indeed much more comprehensive. Would you mind if I add it to XojoiOSWrapper ?

You’re welcome to. The only thing I’m worried about is conflicts with other libraries (or including multiple libraries that need this). That’s why this really should be a built in method. I’m not sure its possible to be able to declare a namespace for an extension method. You’ll also want to add string conversions for Color, Date(Desktop,Web), and Xojo.Core.Date. I also created a ToString Conversion for Desktop/Web. It just calls the ToText method and then outputs that as a string to make implementation easier.

Thank you. The namespace is not an issue if the method is made public, then to call it will require using the name of the containing module, for instance wrapper.TextValue. I do not like the idea of putting a prefix or suffix in the method name, such as TextValueMB.

That’s only if you dont make it an extension method. My example has it as an extension method, allowing you to do “a.TextValue”. It is much more convenient but would cause naming conflicts if anyone else did this.

True. I do not think there is an ideal solution. You could do TextValueBN like Christian would do TextValueMBS. I cannot help to find that kind of cumbersome.

Yet, the user can indeed run into conflicts when mixing several modules. For instance, I have encodeBase64 in XojoiOSWrapper, and noticed Phillip Zedalis’s GlueKit http://www.dev.1701software.com/blog/2015/1/20/introducing-gluekit has it too. So if someone drops both in his project, he will end up with an issue when using encodeBase64…