[quote=186683:@Norman Palardy]An integer property prevents us from ever doing certain things with Auto
Things we’re not discussing at this time.
Really.[/quote]
I rather like a string like Introspection does with t.Name.
GetTypeInfo is a constant expression, so there’s no reason it would have to be anything other than a pointer comparison.
I don’t mean the comparison would be slow. I mean the actual work of retrieving the type info. You’ll know better than I would of course, but I thought the speed issue complained about in this thread is GetTypeInfo itself.
No, the gripe is that you have to call Xojo.Introspection.GetType and then compare the result’s name against text literals.
That’s only part of it. Read more of the thread. The initial complaint was that GetTypeInfo is much slower that the Variant.Type property. That is only one execution. In a select case, I imagine the effect would be even more pronounced.
There is no GetTypeInfo function in the new framework.
I think we all mean Xojo.Introspection.GetType.
That won’t work because you have to pass an Instance of a class, not a class. i.e.
GetTypeInfo(String)
//vs
dim s as String = "John"
Xojo.Introspection.GetType(s)Two different methods. The example Joe gave is the first, GetTypeInfo().
Well, one is an operator, the other a method.
I think what Joe is getting at is though this can’t currently work, that is one option they are considering in the future.[quote=186646:@Joe Ranieri]I suspect what will end up happening is something like this:[/quote]
So yes, I was wrong, Xojo.Introspection.GetType is not what was meant by GetTypeInfo. But that doesn’t mean such a thing can’t be added to the new framework in the future.
As joe said something like the following may occur in the future
[quote=186646:@Joe Ranieri]
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]
What you have TODAY is NOT necessarily what you’ll have to do for the rest of time
Please file a bug report on this. I think this should be legal.
Why is this new data type called when it is non-automatic as non-automatic can be… (so sorry had to much red wine accompanying a fantastic pasta dish).
It should say … called “Auto” …
Got a better name for it? I agree the name is weird. I really dislike it, but I haven’t been able to come up with anything other than “Any.”
Any is actually a type in quite a few languages for this exact purpose. Describes the purpose quite well, I think. I am guessing though that we are stuck with Auto. It is a weird name when you think of it though.
Yeah, I don’t see the name changing.
Yeah, I do. It’s called “Object” - look at how other languages handle this. There is no need for an Auto or Variant type. They just use object and every primitive has an Object Wrapper class that auto converts when needed. I really wish Xojo had done the same thing. This would also solve the issue of not have Nullable versions of all the primitives.
For example,
dim int1 as integer = 3
dim int2 as Xojo.Core.Integer = 3 //Uses slightly more memory, but is more versatile (can be null)
Then methods would auto cast as needed
doSomething1(i as integer)
doSomething2(i as Xojo.Core.Integer)
I could pass int1 or int2 into either of those methods and the compiler would automatically cast it to an integer or Xojo.Core.Integer.
The only concern would be if int2 was null and you passed it into doSomething1() it should throw an exception.
But there could be a helper method like int2.IntegerValue(0) that would be use 0 if the value was null.
BENEFITS:
No need for Auto.
Adds nullable primitive types (which is still very highly needed)
Libraries are more shareable and usable, especially for Javascript and JSON where you sometimes need NullableInteger types etc…
[quote=186902:@Brock Nash]Yeah, I do. It’s called “Object” - look at how other languages handle this. There is no need for an Auto or Variant type. They just use object and every primitive has an Object Wrapper class that auto converts when needed. I really wish Xojo had done the same thing. This would also solve the issue of not have Nullable versions of all the primitives.
For example,
dim int1 as integer = 3
dim int2 as Xojo.Core.Integer = 3 //Uses slightly more memory, but is more versatile (can be null)
Then methods would auto cast as needed
doSomething1(i as integer)
doSomething2(i as Xojo.Core.Integer)
I could pass int1 or int2 into either of those methods and the compiler would automatically cast it to an integer or Xojo.Core.Integer.
The only concern would be if int2 was null and you passed it into doSomething1() it should throw an exception.
But there could be a helper method like int2.IntegerValue(0) that would be use 0 if the value was null.
BENEFITS:
No need for Auto.
Adds nullable primitive types (which is still very highly needed)
Libraries are more shareable and usable, especially for Javascript and JSON where you sometimes need NullableInteger types etc…[/quote]
The overhead of making all intrinsic types be objects is huge. Like you mentioned, you also run into potential problems with unintentionally passing around Nil. It’s much better to have nullability encoded explicitly into the type system, in my opinion.