Not an actual problem, but just some thoughts.
Given this line:
if i=0 then Var j as Integer=MyMethod
(where i is defined as integer and MyMethod returns an integer)
One gets a syntax error on that line.
For me, this code makes perfect sense: call a method in a temporary, not used, variable (similar to “Call MyMethod”). I can’t see a valid reason that this line produces a syntax error.
Because that syntax is not, and never has been, supported. And even if it were, j would go out of scope immediately and not be available anywhere else in the method. Just use Call. That’s what it’s for.
Well, my question is rather “why” than acknowledging the fact.
I’ve talked about these in my original post, and am aware of them.
I’m just wondering why this isn’t supported, as it would be valid.
It would equal to this:
if i=0 then
Var j as Integer=MyMethod
But these are 3 lines instead of one.
And replacing with “call” removes an indication: the type of variable being returned. Not necessarily always helpful, but can be, sometimes.
Submit an Assue, but don’t hold your breath.
Still won’t explain why it’s that way.
Well, a compiler uses a language model, that defines what tokens are expected.
So the Xojo language model probably defines that after the “then” token, there can be a newline with instructions followed by “end if”. Or there can be a normal instruction, but no dim line.
This probably has a reason when they designed the model.
Because it simply isn’t. It was a design decision made decades ago and affects the inner workings of the compiler. It may be a reasonable feature request, though, so go ahead and file a request in Issues.
As it was said above: the var goes out of scope immediately, call should be used. Difficult to see a use case for this syntax.
Thanks for your answer.
I take it as I just have to acknowledge it was designed that way, with or without good reasons.
I see one. With the variable, you keep a hint as to what the method returns. Not a frequent use case, but I’ve seen situations where this hint can be useful (e.g. when there are several methods with the same name, you immediately see which one you’re calling).