Re: operator overloading
Wojtek wrote:
Just look at all the posts which mention initial caps for classes, camel
case, indentation, etc.
Those aren't policy statements, those are convention statements, and they
don't matter a jot to the compiler.
For that matter it's perfectly permissible to write equals() and hashCode() to
be inconsistent with each other. You'll get weird behavior from API classes
(like Maps, for example), but that's documented. This is much more serious
than spelling a variable with an upper-case first letter, yet it's allowed.
That doesn't mean that the methods of Object are broken, nor that collections
classes are broken. The documentation tells you what to expect, and makes a
recommendation. The rest is up to the programmer.
Smart programmers will follow the recommendations.
Understand that there are different domains of applicability to the rules.
Disallowing the use of 'goto' as a variable name is a language rule - it is
inflexible and compiler enforced. Making equals() consistent with hashCode()
is good engineering - programs work better that way and you can use libraries
designed around that assumption. It's good for the computer, but not
required. Following the naming conventions is not even for the computer - it
makes literally no difference to the compiler or runtime. It's for the
"literate" part of "literate programming" - the fact that source code is a
human-readable and human-read document. Naming and layout conventions help
the humans and their discourse.
--
Lew