Do you know some funny inconsistency?

2021 r1.1 Windows locale BR

2021 r1.1 Windows locale BR

1 Like

Toss in all the various MouseUps on different controls
Some return a boolean
Some dont

2 Likes

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 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 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

image

That would be nice
Compiler guy would have to alter compiler to make that work :stuck_out_tongue:

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