@Norman Palardy, I am all for Auto and no automatic type conversion. I never liked that about Variant, it’s dangerous. I am a big strict typing guy. I am all for less memory. I am not for Variant. What I am for is quicker type determination. In most cases (that I use Variant for), I am simply interested in, what intrinsic type is it. Integer, Double, Object, etc… If it is an Object, then I will use other means to determine it’s type information, one of which is Introspection, another which is IsA.
Auto’s purpose is to store a variable of an unknown type. If I know what type the variable is, then I would use a real type when creating the variable. Therefore, if Auto is to be faster in real use, (i.e. using to store a value of an unknown type) then Auto has to have a fast type determination function. We are not asking for type conversion, but type determination.
And again, nobody is arguing that you shouldn’t be allowed to use Introspection if that’s the level of detail that you need, only that it’s not as fast as the Variant.Type property in cases where that’s all you need.
I said no such thing
What I did say was “Additions / changes to auto will happen slowly & carefully”
And that includes making NO changes if that seems the right thing to do
I’m kind of curious how Auto is being used in the IDE without causing slow downs? Maybe a good example of how we are suppose to use Auto without introducing performance problems would solve this discussion as well.
I should say faster, easier and safer type determination. That’s what I’m hoping for. Right now Auto lacks in all three of those areas compared Variant. Again, not type conversion… I do not like that at all, it’s evil :-). Type determination though is our friend.
Auto uses less memory to store values, preserves type information much better than Variant, and lacks all of Variant’s implicit conversions. What it’s missing is a way to efficiently compare the value’s type to a predetermined type (and do so without using text literals).
I suspect what will end up happening is something like this:
Select Case Xojo.Introspection.GetType(var)
Case GetTypeInfo(String)
// Do something
Case GetTypeInfo(Integer)
// Do something
Case GetTypeInfo(Double)
// Do something
End Select
[quote=186646:@Joe Ranieri]Auto uses less memory to store values, preserves type information much better than Variant, and lacks all of Variant’s implicit conversions. What it’s missing is a way to efficiently compare the value’s type to a predetermined type (and do so without using text literals).
I suspect what will end up happening is something like this:
Select Case Xojo.Introspection.GetType(var)
Case GetTypeInfo(String)
// Do something
Case GetTypeInfo(Integer)
// Do something
Case GetTypeInfo(Double)
// Do something
End Select[/quote]
Wouldn’t this be very slow to gather type info for each case statement?
I don’t see how it would be ever possible for introspection to approach the speed of (never mind the simplicity and readability of code using) an integer property.
That is the concern… And I think that practical issue overrides edge case issues with using an integer property in most people’s opinion.
Sure
That’d be plausible
Just saying this this is possible to speed up so you don’t have repeated hits without Introspection doing it.
But this is predicated on joes “suppose …” post that doesn’t exist today.
[quote=186673:@Karen Atkocius]I don’t see how it would be ever possible for introspection to approach the speed of (never mind the simplicity and readability of code using) an integer property.
That is the concern… And I think that practical issue overrides edge case issues with using an integer property in most people’s opinion.
Karen[/quote]
An integer property prevents us from ever doing certain things with Auto
Things we’re not discussing at this time.
Really.
