Re: References and comparisons
Lew wrote:
At a minimum you would expect a Java programmer to understand
primitive types and String.
Mayeul wrote:
Understanding is different to knowing by heart absolutely every single
detail that does not matter to the language's user. Though it is not
implementation details, it is on the same level.
So you're saying someone can call themself a Java programmer and not even know
"by heart" how to use primitive types and String?
Lew wrote:
If you can't trust the guarantees made about String equality,
Mayeul wrote:
I can trust what is guaranteed. I can't trust the current class I'm
working on makes it clear enough whether I meet the circumstances where
it is guaranteed. Nor do I need to.
We were talking about the guarantees the language makes, in particular about
intern()ed String identity.
Now that I think about it, this is mainly due to bad architecture design
and spaghetti code I have to work with, but I expect it exists in
significant amount generally everywhere.
Besides, I'm sure I could construct legitimate situations where it
wouldn't be immediately clear whether '==' is good enough for checking
for same content. Aside from null reference possibility, .equals() just
always is.
We were talking about the guarantees the language makes, in particular about
intern()ed String identity.
Lew wrote:
or don't understand why you should use 'equals()' even when you know
'==' will work,
Mayeul wrote:
Actually, I did understand, it just happened that I understood something
false.
Interesting bit of sophistry, that.
By "understand" in my post, naturally I meant "understand that which is not
false". I would say that if you "understand ... something false" about String
equality, that you do not understand String equality. As a professional Java
programmer, you should understand (the truth about! ) Java primitives and
String. If you don't understand (the truth about! ) these things, then you
don't yet know Java well enough.
And I still understand why I prefer the operator that always work,
except maybe when it clutters performance.
Lew wrote:
or haven't learned that concatenating literal String instances yields
a single literal String instance, you have not reached minimum
competence in Java.
Mayeul wrote:
I think you are just deciding what matters a Java programmer knows, on
your own. This detail is unimportant unless the programmer is making a
compiler, a JVM, or designs a very clever String utility API.
How can you seriously support the idea that a person can claim to know Java
without even knowing how to use String and the primitive types? That is
clearly among the most basic understanding of the language that there is.
And I can tell you from experience that knowing this information is critical
to writing Java applications. It's part of the language as such. For
example, if you don't know how compile-time constants work, you will not
understand why you get the wrong values when you recompile the class that
defines one but not the classes that depend on that value.
I understand knowing this (and anything for that matter) can help
debugging. It just does not seem to happen a lot in practice.
It happens enough that I've seen Usenet posts and articles about it. This
very thread itself is an example.
It's not like I'm saying that a Java programmer has to understand
/happens-before/ at a minimum, though certainly one could make that claim.
I'm only saying that one has to understand String and the primitive types.
What do you claim is the minimum, that a person understand that most Java
systems name source files with a ".java" extension? How can you seriously
support the idea that a person can claim to know Java without even knowing how
to use String and the primitive types?
--
Lew