Stephan van Hulst wrote:You have some very good points here, I must admit.
So, relational operators depend on the whether the data types of the operands are signed. Any other operators you can think of?
Stephan van Hulst wrote:Because the onus is on those who want a feature added to the language, not those who want to preserve the language as it is.
Your argument basically comes down to "I want the unsigned keyword because I'm not interested in solutions that don't use the unsigned keyword".
The source of your problem is that you're using magic values in code. If you declare constants, you don't have this problem:
Stephan van Hulst wrote:I am one of those folks who believes the lack of an unsigned keyword in Java was the right choice. To date, I have to find a good argument in its favor. People usually mention image processing, but they never give a concrete example of an operation that's easier with unsigned data types than with their signed counterparts.
Stephan van Hulst wrote:I've really disliked C#'s naming conventions from the very start. There's no real advantage in looking at an identifier and knowing it refers to a method, field or property through the casing alone. A member is a member is a member.
It would be more sensible to use a difference in casing to indicate that a member is static, for instance. A huge disadvantage of the current conventions is that I can't see if an identifier refers to a type, a property or a constant.
A really annoying situation is when I have a nested type, and in the enclosing type I want to add a property of the nested type. In many cases you would want the names to be the same, but you can't declare two things with the same name.
Stevens Miller wrote:This prevents what I would have thought was an advantage of properties, which would be that if you needed to replace a field with a property (so that you could so some processing in that property's getter/setter code, whenever it was accessed), client code wouldn't have to change.
Yup, this is pretty stupid. Since this is the case, I hope that you still never give fields higher visibility than private.
Depending on my mood, I don't use fields at all. Sometimes, just so all my data are grouped together and also conform to the style rules, I will forego fields completely and just use auto-properties.
Stephan van Hulst wrote:I don't really understand, what additional considerations does that use-case introduce?
Stephan van Hulst wrote:For instance, if my setter kept track of how often a property was changed, or if it notifies listeners, it must do nothing if the actual backing data store was not changed:
Stephan van Hulst wrote:I once found the following statement in our code-base that an intern had written:
I removed the line and our product stopped working. I put it back in and then yelled at the intern (not really, but I was quite upset).
I put it back in and then yelled at the intern (until I remembered that I was the one who wrote the property code).
Fred Kleinschmidt wrote:Wouldn't something like this be simpler?
Stephan van Hulst wrote:I didn't realize that was a requirement, as you wrote the following:
Stevens Miller wrote:The lockOutInEffect flag is cleared by a different method, at some appropriate future time.