OK. So say you want to create a control with properties Color and Text. Since they are reserved, you won’t be able to use them. Pity. I ran into that with “Text”.
Is it that terrible to use Car.Clr and Car.Txt ?
I tend personally to use the same kind of descriptive properties name, though.
Car.BodyColor and Car.PlateText. I also like Markus suggestion of Car.Colour, or like Arnaud, using French properties like Car.Couleur and Car.Texte.
That said, you can perfectly go around the reserved names. Save as Text, and edit property names to your liking
Either this way, or first name the property as “ABC” and then rename it to “Color” via Search and Replace. This works. You just can’t enter the name “Color” directly in the IDE at the moment.
For example, Xojo has introduced the ShadowBrush class. I think ShadowBrush.Color reads nicer than the double ShadowBrush.ShadowColor, like the rest of the properties (ShadowBrush.BlurAmount and ShadowBrush.Offset). But that seems to be a matter of taste, as evidenced by the thread here.
But if I have an instance (or subclass) of a Bread class named RyeBread It would be nice to be able to have a property named Color in Bread to do:
RyeBread.Color = &cB9906100
Instead of RyeBread.BreadColor = &cB9906100
Not many data types names fall into that category of usage… Color and text are the most likely ones.
What’s worse is when the IDE allows you to use a name that you shouldn’t.
For example, create a class named, ‘Team’ and give it a property called, ‘Name’… as in Team.Name… and then drag it into a window as a control. No seriously, don’t do this. <https://xojo.com/issue/63135>
I’ve tried your example and got yet a different, still odd, result.
Up to the control’s name becoming empty, I got the same behaviors.
Then, still following your steps, I renamed the class’ property from “name” to “fullname” and selected the control on the window again. Unlike your example, the control’s name remained empty and I could rename the control freely
BUT I then realized the “fullname as string” property has moved from the class to Window1! The Team class has now no property at all, which explains I didn’t get the last half results you got.
A fun moment…
I believe that majority of the discussion regarding variable, property or parameter names using ‘Color’ or 'Text" are moot. Naming preference should not be forced into the language. Instead, we need to consider that “Text” and “Color” can be disambiguated as referring to the class or referring to the property name in a given context. And I believe that in all cases the compiler is capable of doing this.
The many examples given here of instances where .Color would be appropriate are examples on how this unnecessary restriction is a nuisance. I am certain we all will survive regardless, yes.
As for naming a property “Name” on a class, that is a peculiarity of the usage of the name ‘property’ on a class. In other programming languages the name of the class is not also stored as a property of the class. In Xojo it is, so the usage of the name property on a class is restricted. It seems that this peculiarity is causing problems and should be addressed.
@Greg_O_Lone, you‘ve closed the Feedback case with the hint doing search and replace is „buggy“ at this point, since we are able to rename a property to „Color“. Please don’t change this. There are Couple of Situation where „Color“ is a useful property Name and since the Compiler doesn’t have and problem with it, you shouldn‘t change it. Otherwise this would break code.
You can’t name or rename a property to “Color”. It prevents you from doing that and the fact that search & replace let’s you get around that limitation is a bug.
Just sayin… you’re asking for a world of pain down the road doing this.
I’m sorry @Greg_O_Lone, I have to disagree with you. As I stated above, it is possible to give properties the name “Color” and the compiler has no problems with it. The code works perfectly. So where is the problem? Why do you say it is a bug? At this point, please don’t create unnecessary, new problems by forbidding us in future Xojo versions what is currently possible, albeit in a roundabout way. @Xojo
Are you suggesting that there is a scenario where the variable can not be disambiguated from the class? That would be the major issue if there were such a scenario. Which I am willing to be there is, I just want a concrete answer to help me rationalize the opposition to allowing it as a variable name.
That is what we had 30-40 years ago when I programmed my Apple IIgs…
Also, if you start to use common programming words, how can you tell this variable is mine and that one is from Xojo, Linux/macOS/Windows…
I too, for grouping reasons, I use some user defined syntax variables like shown above by Thom, agreed by Jeff.
For ListBox, when only one inthe window, I use LB. Faster to type and autocomplete is a dot near to help me not typing the whole “command“…
Same for TextArea (TA), TextField (TF), etc.
And when there are more than one Control of the same kind, I simply write:
TF_Name, TF_Birth, TF_City, etc.
Fast typing too, autocomplete is of help, no error on reading (usually).
And I always use the cases (Upper-Lower) to avoid brain collision like;
.childat() read as Child Date… instead of .ChildAt().
Remember the way we read texts (by bunch of characters, so errors is at our doors) and remember things (this I do not know).
So, no, Color should stay a reserved property name because of the above and there are so many ways to write a variable nam (Clr as prefix or suffix for examples).
