Color shouldn't be a reserved property name

Since 2020r2 introduced

Text should not be a reserved property name feedback://showreport?report_id=61952,

I’d love to see the same behaviour for Color.

Color should not be a reserved property name feedback://showreport?report_id=62263

@Xojo what do you think about it?

EDIT: You might argue that the Text data type is deprecated. However, the name Color is quite common just like Text for a property of a class.

Also, the following line of code works without problems with 2020r2. The compiler doesn’t get confused.

Text Test

Uh… no.



1 Like

As the author of the infamous Dim Session As Session = Session line, I can confidently say this is a bad idea. While it technically works, the main thing it does is reduce code clarity.


Just use Colour - it’s correct spelling, clear meaning, and makes it clear that it is one of your defined properties.


Or give it a more precisely name like

  • BackgroundColor
  • BorderColor
  • FillColor
  • DrawingColor

Whatever happened to hungarian notation?

Var thing1 as color
Var thing2 as string
var thing3 as integer
//cant look at a row that says  something = thing1.  and know what its doing

Var  colThing1 as color
Var strThing2 as string
Var intThing3 as integer

When you get an error on line

colThing1 = 76

it should be obvious why.

1 Like

I personally find that annoying. I’d rather do something like

BreadLength As Integer
BreadFlavor As String
BreadAge As Interval

This way all my related values sort together. Unless I’m using variants, the compiler checks types for me, so I don’t really need the type in the name.


No thanks to hungarian notation. I group controls by prefixing them. But only because there is no grouping in the IDE.


at least something like this should be possible
Var color As Xojo.Color

reserved property

agree that is is very annoying and i always must use a unwanted name.

1 Like

Oddly, thats what I do, rather than what I said… :slight_smile:
Hungarian is a hangover from my indentured C coding days.

I guess the point we are all making is avoid generic terms like text, color, string, int. because firstly it IS confusing, secondly it may cause odd compiler issues and thirdly, you never know when it will become an issue in a future build.

The day Xojo adds BreadLength to the language will be a long time coming.


thats why key words dim,var,as,new have a meaning for the compiler.

I guess the point we are all making is avoid generic terms like text, color, string, int.

yes frequently i can not use a variable name because its disallowed.
i not like prefix or suffix or hungarian notation for some of the “conflict” names.
a bad habit is to use german words instead :partying_face:

It was introduced to solve a problem, but since the problem no longer exists… it’s a solution trying to find a problem.

i discover long ago never to use the variable backgroundcolor or property or Notes.
that is why these days, i remember to use ABCNotes or something like that.

I always use very descriptive names. It is much easier to maintain afterward.

Color as Color, even if it was possible, is a recipe for poor programming.


To be clear: I do not use this construct internally.
However, I do not consider the designation of a property like Car.Color to be wrong or even “poor programming”. It is just a matter of principle. After all, it is now possible to name things like CustomEditor.Text again, even though the Text data type is still present (albeit deprecated).

I’d argue your example is still a bad one. It paints you into a corner. It should be Car.PaintColor or Car.ExteriorColor. Because what about the upholstery? Just calling it color isn’t descriptive enough at best, or at worst means something needs to change later when additional color properties are added.


When I run into such situations I check the thesaurus.

So, when I need a color:

Var tint as Color // usually with some like fillTint or borderTint

Last year, I made the exercise to use French variable names in one of my projects, mainly to check if it was possible and maintainable.
I discovered Xojo actually accepts accented characters, and, as an extend, glyphs for variable names.
This was actually a fun experience. And, of course, I didn’t have to watch out for reserved names.

So, for example, you can change this:

Var ThisPhoneIsWaterProof As Boolean
Var :phone::open_umbrella::heavy_check_mark: As Boolean

(dummy example, of course).

1 Like

I agree. The compiler should be able to disambiguate based on position alone. Additionally, I would like to see “Text” and other keywords not colored when they are in the variable/property name position.

Although it can be argued that “Color” is not specific enough for programers as a property or variable name, that is besides the point. (I mean this part kindly, we name variable x,y,z,i,g,g1,g2,iiiiii frequently. And it’s my code, not yours.)

I would love to see a day when Xojo had a case sensitive variant as of the language available. I know that will never happen. Regardless, ‘color’ should be allowed as a property name unless it can be demonstrated that the compiler truly can’t disambiguate it.

Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.