2021 r1.1 Windows locale BR
2021 r1.1 Windows locale BR
1 Like
That was true in the API1 era, should not be this way in the API2 era.
Why? Because API2 changed the behavior from function(type) to type.method(), so as in Xojo you canāt write (123.4).method() and the IDE is not smart enough too and canāt correctly infer the type, you can help it (and the autocomplete) explaining the type as an āunnecessaryā cast that does nothing except enabling API2 constructs like
Function Method(Extends Value As Double) As String
Return Something(Value)
End Function
Rick this is all kinds of incorrect
API 2 is 99.9% EXTENDS methods and doesnt change the underlying compiler in almost any way (VAR is the only thing I can think of that HAS been added since API 2 started)
You can see this when the autocomplete hints show at the bottom of the code editor
Its certainly NOT relevant in this case as Integer(value) and Double(value) are casts
Not function calls.
Not API 1 or 2 methods.
Casts that the compiler handles directly.
To change the semantics of a type cast someone would need to alter the compiler
EDIT : I suspect the reason the compiler barfs is that the āfloating point literalā has no way to be cast to a Double
Same as why ā1234ā.length doesnt work
ā1234ā is a text literal - not a string and there is no way for us to extend ātext literalā
You may not read it correctly, I almost completely disagree except the part
And would add:
To change the semantics of a type cast someone would need to alter the compiler to be able to handle correctly API2 constructs as expliciting types (enabling correctly the extends).
Disagree all you want
API 2 isnt involved in any way
It hasnt changed the semantic of casting in any way
Double(value) is NOT a method call of ANY kind
Nor is Integer(value)
They are casts
You are still not reading correctly.
Please tell me what Iām missing ?
What you mean by this for example? Did I say something like that?
just whats stated on the bug report
Dim i as integer = integer(24)
Dim r as double = double(24.5)When you try to compile, first line is accepted without any warning and i=24
But second line is not accepted with this strange warning:
āType mismatch error: Expected Double but got Doubleā
which was closed by Joe as not a bug with a long explanation
Those two are BOTH casts
not method calls
not constructors
not API 2 anything
CASTS
The literal (24 or 24.5) is at compile time, converted into a numeric type, and then the cast is attempted on that numeric type IF legal
Note Joe lists what CAN be cast
Double is NOT in the list
That was a vision of the past that CANāT be maintained today.
The important part Joe said for our conversation is
"type casts take a value and reinterpret it as some other type. The exact rules differ based off of the type of the value being cast.
If the value being cast is an object, the value can be cast to different class or class interface types. This will get type checked at runtime and throw a TypeMismatchException is itās an invalid cast."
It must be changed to add "ignore if the type cast is the same as the target āvalueā, just use it as is, and apply the proper āmethodsā (function extensions) requested.
Currently casts are like C++ reinterpret casts
Function extensions ARENT involved in any way - currently
In fact I suspect this is all evaluated and generated at COMPILE time since its a literal expression
Making it use actual functions/extensions would, I believe, be a significant change in behaviour for the compiler. And would introduce a function call that likely doesnt exist today (Iād have to disassembled the code to be sure)
Dim i as integer = integer( IntegerLiteral ) // 24 is maybe an integerLiteral more likely a numericLiteral
Dim r as double = double( DoubleLiteral ) // 24.5 is possibly a doubleLiteral more likely a numericLiteralIs what youāre asking for is ānumericLiteralā - quite literally a type that is likely internal to the compiler we rarely see evidence of - to be ācastableā to ANY type ?
Or to have a method named āIntegerā, āDoubleā , āSingleā, one for every numeric type, that can take a numericLiteral and return the right value like a function call ?
either is, IMHO, a decent sized change which I wont hold my breath about
Ohā¦ Hopefully that means smaller builds in the futureā¦
why would you expect that ?
I sure dont
I can be hopeful, I care about app size and try my best to keep it down.
And I donāt care. I just want a Xojo way of doing what is expected like
That would be nice
Compiler guy would have to alter compiler to make that work 
Which compiler guy?
Geoff has claimed to me they have the ability to fix compiler bugs
This would lead me to think he believes they have one
Iām not so sure
Adding VAR to the grammars is the only real thing I can think of in the years since Joe departed
And that one should be trivial