[quote=186286:@Thom McGrath]Because an integer property can’t tell you enough. With variant, should type return TypeDate or TypeObject for a Date? Both are true. Obviously, it should return TypeDate, but that implies it is not an object.
Arrays are a mess too. An integer just can’t give you the details effectively.
[/quote]
I don’t see how Date is an issue as long as it is documented.
As to arrays, one could have a BaseType property and and isArray Boolean 0r something like ArrayDimensions as Integer which returns 0 if not an array.
If you need more (which would be seldom) THEN one could use introspection.
In any case it seems introspection introduces too much overhead for such a common operation.
One often has tradeoffs for speed. For speed in simple cases being able to use a type property or properties would be great… For a complete description that works for all cases use introspection.
To me that is analogous to the Val, toText situation before Xojo Inc relented and gave us functionality analogous to Val in the new framework.
As I mentioned above it is the difference between the academic and teh practical. As I said in the Val discussion , While not perfect the old framework had a reasonable balance between safety and practicality (speed).
The new framework is more of a nanny and leans more towards academic “perfection”. As with the Val situation , this case is one where the practical needs to be recognized and accommodated even if the solution is not all encompassing. Introspection is there for the more complicated cases and/or sped is not paramount, and a type property is could be for the majority of cases where it is sufficient and much faster.
I would love to see it getting opened again.
To use the new dictionary class with auto type I need a quick way to go through all keys, get their values and make a big select case based on the value type to handle each type, e.g. to convert from xojo.core.dictionary to NSDictionary.
That would be nice, but as much as I love Introspection, it’s still not as easy or as safe as a .Type property.
select case xojo.Introspection.GetType(var)
case "String"
blah()
case "Integer"
blah()
case "Doubl" // notice typo
blah()
...
end select
// vs
select case var.Type
case Auto.TypeString
blah()
case Auto.TypeInteger
blah()
...
end select
Sure, I guess you could have another feature request for constants that may be returned from .Name, but that will never be complete, as .Name returns the class name of any object. Thus, you really need something like:
select case xojo.Introspection.GetType(var)
case "String"
blah()
case "Integer"
blah()
case "Doubl" // notice typo
blah()
case else
if var isa Object then
blah()
end if
...
end select
In addition you have to scan the xojo.Introspection.GetType(var) for parentheses and commas, because of one- or multi-dimensional arrays. The solution with Type and IsArray / ArrayElementType worked really well.
The problem with the old framework is that it was ambiguous in many edge cases. This led to odd behavior and very subtle bugs. The new framework is designed to NOT be ambiguous so the edge cases don’t happen.
Most people used variants properly. A lot did not and the compiler didn’t warn them about it. I believe that over time the new framework will get loosened up a bit just like they did for ToText and Parse. But, until we identify those spots and enough developers complain about it I think it will continue to strict.
FWIW, I believe that they have future plans for Auto that they’ve not revealed to us. They have a few things on the plate to deal with first.
Jeremy, your Introspection code is a little weird. Realistic code would be something like
[code]Dim Info As Xojo.Introspection.TypeInfo = Xojo.Introspection.GetType(SomeObject)
Select Case Info.FullName
Case “String”
Case “Text”
Case “Integer”, “UInt8”, “UInt16”, “UInt32”, “UInt64”, “Int8”, “Int16”, “Int32”, “Int64”
Case “Double”
Case “Date”
Case “Xojo.Core.Date”
Case “Xojo.Core.MemoryBlock”
Case “String()”
End Select[/code]
Introspection makes dramatically more information and is unambiguous. You can “see” the difference between a single object and array of objects easily. You can detect the size-specific integers too. Everything you could possibly need to know is there. An Integer property cannot do that. Your own example even used an “else” for objects, which is unnecessary.
Is it more work? Absolutely, I do find it annoying myself. But it is so much better than an integer value.
Personally, I would rather TypeInfo.FullName NOT include the () characters for an array, so I can simply use TypeInfo.IsArray inside case statement. Both a single item and array would have the same name. But that’s a different discussion.
Select Case anAutoVar.Type
Case Auto.TypeString
Case Auto.TypeText
Case Auto.TypeInteger, Auto.TypeLong
Case Auto.TypeDouble
Case Auto.TypeDate
Case Auto.TypeObject
Select Case anAuto
Case IsA Xojo.Core.Data
Case IsA Xojo.Core.MemoryBlock
End
Case Variant.TypeArray + Variant.TypeString
End Select
I don’t see the plus of information.
It’s shorter.
It’s more readable.
It’s safer (no string literals).
Auto.TypeString will never exist. And TypeDate (I’d expect) would only be true for Xojo.Core.Date, but not Global.Date. In that case, you would need to compare against Object. Also, IsA doesn’t work on Auto.
I don’t think anyone disagrees with that point, but using Introspection is slower, and the compiler doesn’t help if you introduce a typo, as Jeremy pointed out. What’s more, if you need that level of information, there is nothing to stop you from using Introspection and taking the performance hit.
The point is, Auto doesn’t offer that alternative at all and, as such, it’s hard to see where you would choose it over Variant as an experienced programmer.
And auto is billed as the new Variant that is faster and less memory. That may be the case in a few very limited situations, but in practical application, it is slower and more code.
It’s not going away any time soon I’m sure and until the above issues are hashed out on Auto, I can’t see a reason to use it.
I’m not sure about the “going away” part, but I’m talking about targets where we do have a choice. In iOS, it’s easy to see why we’d choose Auto over something that doesn’t exist.
No, the classic framework is not going away soon. But it will someday. The xojo framework is mature enough now (not complete though) that new code should be written using only the new framework wherever possible. Porting is very much not easy. So that’s why you’d choose Auto over Variant. Also if you wanted to write “universal” code.
I don’t see a problem with Auto outside of slow introspection in comparison to variant’s type property. That would be where I’d focus engineering efforts if possible.
If used properly, Variant/Auto should only be used where you don’t know the type of object you’re going to store. With Variant, you don’t always need to know since it will cast itself where possible, but with Auto you absolutely need to know. So now we are in a situation where we have to add extra code and it’s slower.
Auto is faster for accessing the item stored in it than Variant because there are not automagic conversions.
And an Auto uses 98% less memory than a variant again because there is no provision for auto conversion.
It’s slower to get type information because you have to use introspection.
The biggest issue we see in example code & bug reports is the automagic conversions.
If Auto were Variant without the “automagic” conversions, that would be ideal, and, as convenient as that can be, I have no problem with that “feature” going away. It’s the rest of the functionality I don’t want to lose.
Is revealing the type tied to these conversions somehow?
