While I understand that technically the compiler can sort this out the way that Norman explained it, he left out one very important example.
Lets say you have a Canvas subclass with a property:
color As Color
Now in the Paint event, you try to do something like this:
g.DrawingColor = Color.Red
You’re going to get a compile error because the compiler can’t tell the difference.
https://www.dropbox.com/s/poesmrn7wltgjfd/DontUseColorAsAPropertyName.xojo_binary_project?dl=1
i have no problem with a compiler error that said we have two of the same names.
developers could write
g.DrawingColor = Xojo.Color.Red
g.DrawingColor = Me.Color.Red ← Property
i wish “reserved property name” is optional, maybe special ide settings.
if me define a property i can write Property Color as Markus.Color ← whereby the first is a module as namespace and the second is my class inside.
Eh?
In my eyes, the example you gave is actually correct, the compiler error you made there would show even if you named the property color1 then used:
g.drawingcolor = color1.red
That error is showing that the scope is actually local to the class before it looks for the datatype color which is what I would expect in this situation because of the naming conflict. If you then wanted to do it correctly and you had subclassed canvas and named the property color you would need to use:
g.drawingcolor = global.color.red
to specify that you’re interested in the datatype and not the local property which is the whole point of global, “to refer to items that might otherwise be ambiguous”.
See the example at the bottom of Global - Xojo Documentation, its a shame that the example stopped working years ago, I guess it shows how few people use it.
While I may agree, it’s not always obvious that’s what you’ll need to do to remedy the compile error sometime in the future… certainly not when you’re first writing the code. We’re trying to not only think about when you first create the property, but also what’s going to happen one or two or five years down the road when you come back to the code and make a subtle change say like changing from &cFF0000 to Color.Red. Unless you remembered that you had a property on the class that happened to be named color there’s going to be a bit of confusion.
I totally agree, that would need to be part of the fix/implementation as well as liberal use of comments. You should be able to right click the Color of Color.Red in your example and for Go To CustomCanvas.Color to be shown which would make the problem a lot more obvious. Then the IDE would need another tweak as Color in this instance would not be a Data Type so should not be highlighted as such which again would make it more obvious. Yeah, plenty of work for the minute number of people that will want to type Car.Color instead of Car.PaintColor.
In my humble opinion, there are way more important things to spend time on than this 
Exactly. And that’s why Xojo shouldn’t change anything and just let us continue to use the Search/Replace detour to name the property In Color and not block this way.
If I hadn’t opened this thread and feedback case, the Xojo team wouldn’t have known about it anyway, after all, this has been possible for decades.
Well, no, those are different things. Fixing the search field helps the new user who might not realize that’s what’s going on. You are the outlier case here.
Not adjusting the compiler is a separate issue.
It should be done.
Actually, thinking back on what I wrote above I went off to see how “well” they implemented Text in 61952. They allowed Text as a property and didn’t fix the highlight of the keyword when its not a keyword and also didn’t fix the Go To when its used locally in a class.
So it seems they did the minimum required to get it in there (I totally understand getting the feature in there quickly instead of spending uberhours trying to polish it), so I don’t really see why they cant “just” remove the code that stops Color being entered into the Inspector of the IDE and leave it the same as Text.
Of course that “just” might be uberhours which is why it might not get done.
C’est la vie
I do agree that it is somewhat inconvenient to deal with Xojo’s intended limitations.
But that is the nature of programming: each language has its own limitations, but a good programmer will simply take them into account to get to the desired result.