Aren’t those Xojo keywords?

General
1

Aren’t those Xojo keywords?
Reserved Words

Why can I not use text as variable or property name then?
Why does the code editor color Text as a keyword (TextField.Text)?

Questions, mysteries, inconsistencies…

2

The IDE prevents this because its a bad idea

But this line of code compiles perfectly fine

Dim Text As String = "123"

which indicates that TEXT is not in fact a “keyword” (ie/ one the compiler will refuse to let you use)

3

But text can not be used as the name of a method argument or the name of a property or the name of a method. Error message in the IDE: “The name cannot be a keyword”.

So “text” is allowed for built-in properties (for example TextField.Text) and for local variables but not for anything else. If that is not inconsistent, what is it then? Either a keyword is a keyword and you cannot use it at all as name for any element or it is not a keyword and you can use for any kind of element.

Dim Text As String = "123"

Why is the color used for Text in the editor the color of the keywords? Again this is an inconsistency. Source code looks weird when a variable name suddenly is colored as keyword. And with the built-in controls having a property called Text you cannot avoid it.

4

Unfortunately we had no choice because the TextField.Text property existed before the Text type was created so we had to allow that to prevent breaking user projects.

5

Thats just the IDE not being able to distinguish the “keyword” in a pile of different contexts so it just says “you cant use this here”
But, if you really want to you COULD hack a text project and insert a method or property named “text”
The IDE tries to prevent you from doung things that are going to eventually make your code ambiguous as heck
IF you can insert a property & method named “text” a line like

   dim text as text = text

isn’t so bad for the compiler since

  1. the first TEXT has to be the name of a variable
  2. the second TEXT has to be a TYPE
  3. the third could be another property OR a method and if you have a method named text it will resolve & compile

BUT once you get past this line YOU have a MUCH harder time
Assume that there is a variable and a function described above if you later write

    if text = "" then
    end if

which “text” is going to be used ? the local var ? the function ?
I know exactly which one WILL be used but the rules for WHY this would be this way aren’t clear to everyone
Hence constructs like that DIM statement are, where possible, discouraged by the IDE

Text as properties on controls predated the TEXT type
You dont really want us to go rename them all so you can touch up every bit of your projects do you ?

Code coloring in the IDE is designed to be relatively fast & close enough
Making it perfect would have negative impacts on speed and, until it can be driven by the compiler, would never quite match up with what the compiler actually does
We’d basically have to duplicate a LOT of the parsing & semantic analysis of the compiler in the IDE