and we’d like to avoid the conflicts. It’ll only be convenient for everyone, if everyone marks his stuff.
But in this case, it’d be more convenient if Xojo just added the explicit conversion methods for the auto type.
I don’t think it’s going to happen. That’s why using Variants was bad, in many cases.
Variants were bad because you’d get
dim v as variant = 123
dim c as color = vor
dim v as variant = "123"
dim c as color = vor some variation of this in a lot more code & then the fun ensues
yes, but a few explicit and supported conversions may be good.
e.g. conversion to text. Maybe not from text, but at least define a way to get text.
The new framework is pretty rough around the edges. That being said its super easy to extend it. You only write this boiler plate stuff once.
The objective here is clarity. Before when you did .MagicCast() you relied on Xojo to figure it out for you. Different types and circumstances could cause different failures that have to be handled different ways. Now everything has to be explicit so you are in control of how your app fails. This is good.
dim a as auto = new MyCoolClass
dim t as text = a.TextValue
Now what ?
At least with the code in your hands you can determine what to do.
Built in you have fewer or no choices.
We’re really trying to be VERY careful about whats built in vs whats not so we don’t tie your hands or ours.
If it’s a class, it calls Operator_Convert to get string if available and raises exception if not possible.
dim a as auto = something
msgbox a
should show something.
YOU can do this right in YOUR code
We cant do it generically
I believe that what’s being missed here is that RB/RS/Xojo has always been about making coding easier.
Heck, we can do anything that we want in our code - if we’re willing to:
[ use declares | write a plugin | buy a plugin | write a shared library | write our own extension methods | hire the work out ]pick one or more.
But, that’s not why we purchased RB/RS/Xojo.
It’s a bit frustrating, but we’ve been required to do a lot more of this lately compared to earlier RB/RS/Xojo versions.
Yes the new framework will, at this point, involve more work - its not got 15+ years behind it like the old frameworks do.
Version 1.0 of Realbasic way back in 1996/1997 also meant lots of things you either did yourself or wrote a plugin or simply did without. I still have it here on CD somewhere. And it grew. It gained capabilities in every release.
Thats about where we’re at with the new framework.
Give it a chance to grow.
So is this built in now - no.
Will it be - file a feature request.
In the mean time you can do this right for your usage within the context of your app better than we can.
But didn’t Brock already file one and it got closed.
Which one is it then?
[quote=161112:@LangueR]But didn’t Brock already file one and it got closed.
[/quote]
No - its still open
<https://xojo.com/issue/37800>
No idea since the request he listed here has only been reviewed
The addition of a “Type” property was closed but thats an entirely different request
Cool. Christian’s was closed but Brock’s is open. More targeted to the problem at hand (and may not impact Xojo’s future direction). Thanks for the clarification.
Thanks for the function Brock! Just saved me a ton of time dealing with Autos. Like others, I don’t find the new framework to be very friendly. I much rather prefer the old framework for its clarity and simplicity. While the new framework might be technically superior its usability is significantly less superior. 
I got an error when trying to use extends and also an error since my string was not encoded.
[code]Public Function TextValue(a as Auto) as text
// From Brock Nash from https://forum.xojo.com/19124-auto-to-text
Dim info As Xojo.Introspection.TypeInfo = Xojo.Introspection.GetType( a )
// Handle Strings and Variants
#If TargetDesktop or TargetWeb Then
If info.Name = “string” Then
Return CType( DefineEncoding( a, Encodings.UTF8 ), String ).totext
ElseIf info.name = “variant” Then
Dim v As Variant = a
Return v.TextValue
End
#EndIf
// Handle other Types
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]
Variant’s, while extremely friendly, also tended to introduce very subtle bugs. This function is very explicit and there is zero chance of introducing those types of bugs. I penned a blog post a few years ago that ‘Variant’s are evil’.
Variants are indeed evil
If anyone has used a version control system & saw the various entries in their projects flip flop from quoted string like “123” to 123 and back (or “true” to true) etc that was a result of variants
And truly a huge pain to fix over many releases
I don’t use variants lightly, but when i do their flexibility is a HUGE time saver and the type property is a big help there.
The old framework evolved to make thing easier and coding simpler… that was what RBs basic philosophy seemed to be to me…
As I have said in the past, the new framework is more work and less fun for sure… with much a different philosophy, or at least priorities.
It may be “technically” superior (where complete enough) and make it harder to shoot ourselves in teh foot, but it is definitely (what I first typed was autocorrected to defiantly 
) less “friendly”, makes the product overall less attractive to people like me, overall less productive because of it’s nit picking ways, and likely less accessible to those just starting out that are not computer science majors.
- Karen
Auto is also evil as I can’t use it with plugins.
Karen
At this point in time I can certainly understand why you feel this way.
The verbosity using the new framework is an interim measure while both old and new frameworks need to co-exist in projects.
One of the issues we HAD to solve with the new framework was how to make it possible to use both old & new in the same code.
We knew that simply saying “you MUST rewrite your apps to use the new framework” would not fly in any form.
But the old framework made almost no use of namespaces and that forced us to make the new framework use them rather than just a single global namespace like the old framework. We had to solve the issue of things like “memoryblock” existing in both frameworks. And that definitely makes things more verbose - for now.
As well there is no way to say “only use the new framework” and there could certainly be at some point in the future
However, if you look at iOS as an example, once we can have a “use only new framework” option (like iOS) then the verbosity can drop dramatically because the new framework includes would already exist (which is what we do for iOS)
We need to get more of the new framework fleshed out so a “new framework only” project is possible and very similarly featured to what everyone has used for the last 15+ years