2021 r1.1 Windows locale BR
2021 r1.1 Windows locale BR
I was reading about this not so long ago feedback://showreport?report_id=45327
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 API 2 anything
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 numericLiteral
Is 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