Xojo R2 Reviews

Dim changed to Var:
This looks to me like a “Me Too”.

Index that now starts at 0:
If this is always the case: it is a good thing: we do not have to ask ourself (and look at the LR to be sure): “Is this a 0-based or 1-based value ?”
But I have doubts: I do not read, yet, the FolderItem entries so…

I love the new prepared statements by default but that’s just a small point. From the eagles’ eye perspective the new API is good and helpful but it will take some time. Nevertheless I am more struggeling with the future of Apple and the need for Xojo and a lot of Xojo Devs (including myself) to reduce the dependency there. Catalina is the first macOS I am not going to install soon (another topic).

Yesterday I changed a little project (a C/C++ editor with highlighting, run mode etc.) to the new API and it works without any error. Critical methods are executed even about ten percent faster, and so far I am very pleased with the new API.
The only downside: running/compiling my project takes ages, although I cleared the cache before running the new Xojo version. I dont‘t know what‘s going wrong there …

another one from Jim McKay
https://www.pidog.com/wp/2019/10/10/xojo-api-2-0-and-3rd-party-modules/

[quote=457274:@Emile Schwarz]Dim changed to Var:
This looks to me like a “Me Too”.[/quote]
In name only.
If it was a true “Me too” we could write

Var x=1

yeah var in other languages where it exists behaves vastly different than DIM does
but then that is the nature of those languages and Xojo would have to adopt inferred typing to make VAR similar

[quote=457416:@Norman Palardy]yeah var in other languages where it exists behaves vastly different than DIM does
but then that is the nature of those languages and Xojo would have to adopt inferred typing to make VAR similar[/quote]
which begs the question… why bother doing it at all then? :slight_smile:

If it looks like a duck and you think it might quack in the future, it’s probably a baby duck?!

I’d have made DIM optional so you could write

   dim i as integer
   s as string

there’s a Feature Request for this
<https://xojo.com/issue/56803>

an undrinkable sweet bubbly rosé wine?

not getting the duck references

alternate a system with the opportunity to set alias names would be more helpful.
alias .Value as .Text ^^
alias .AddRow as . Add
alias Array.UBound as .Last
alias .LastRowIndex as .LastIndex
alias Dim as Local
maybe someone can add this to the feature request.

i also have no problem with propertys of the same meaning so maybe its better to have UpperBound and LastIndex together
instead of make others deprecated.

[quote=457537:@Norman Palardy]I’d have made DIM optional so you could write

   dim i as integer
   s as string

there’s a Feature Request for this
<https://xojo.com/issue/56803>[/quote]
As a self-proclaimed language nerd, there are penalties to this approach. Using Dim or Var reduces the amount lookahead required by the parser. At the very least this improves performance. I have no idea how Xojo have implemented their parser but many parsers are single token lookahead by design and if Xojo’s is of this type then dropping the declaration keyword would be challenging. Having Dim/Var also saves a line-position check for each identifier token encountered. It certainly simplifies the internals of the parser when it comes to assignment statements (not to mention assignment override methods - e.g. use of the Assigns keyword) by having Dim/Var.

I would imagine there is little chance that Xojo would add type inference as that would be a non-trivial amount of work and we all know there is no dedicated compiler/backend engineer at present. If only there was someone in the community interested in this stuff :slight_smile:

[quote=457274:@Emile Schwarz]

Index that now starts at 0:
If this is always the case: it is a good thing: we do not have to ask ourself (and look at the LR to be sure): “Is this a 0-based or 1-based value ?”[/quote]

other languages have option base 1.
string commands with 0 index are very annoying …

I never had any difficulty remembering that all string functions are 1-based. What I do have difficulty remembering is method signatures, and while there is a feature in Xojo that solves this issue, it has been broken ever since Xojo replaced Real Studio. In RS, the “Syntax Help” field below the editor would update as you type, so that as soon as you type “Instr(”, for example, the parameters would be shown. In Xojo it doesn’t update while you type - you have to backspace or otherwise move the cursor to force it to update, which is annoying and disruptive. I filed a feedback case <https://xojo.com/issue/50976> nearly two years ago but it’s been mostly ignored. There are so many usability issues like this that have been broken ever since Xojo came to be that I wish they’d take a little time to fix. Little things like this in the IDE are the difference between enjoyable coding and drudgery.

Hah. I just posted something about the documentation being kind of useless to me, on 2017r3, then saw your review.

All kinds of training sites and forum posts are now much less useful because they reference stuff that’s been completely stripped from the docs, making things confusing if you’ve found a solution but the API has changed without clear documentation about the change.

Flex / Bison (lex / yacc)
Single token lookahead should, from what I recall, be sufficient - but I’m not holding my breath
Adding VAR as a synonym for DIM is probably the most trivial change of them all

[quote=457809:@Garry Pettet]
I would imagine there is little chance that Xojo would add type inference as that would be a non-trivial amount of work and we all know there is no dedicated compiler/backend engineer at present. If only there was someone in the community interested in this stuff :)[/quote]
This is likely a much smaller change than something like generics which would require a significant overhaul of the type system

Ah generics - what I wouldn’t give for those.

That’s because they are fowl. :slight_smile:

They weren’t consistent. I don’t really care 1 or 0 based, as long as they all work together. The big problem with 1 based indexes is that it doesn’t play nicely with left or right, which require a number of characters to skip. When InStr returns 1, and you pass that to Left, you get the wrong result. You have to remember to use Left - 1. But Mid DOES use 1-based offsets, so you have to remember NOT to subtract 1 for that function. It definitely makes these methods annoying to all work together. Using a 0 index simplifies all of them, since you can’t logically make Left or Right 1-based.