Rob Spoor wrote:Also, if a class like Coordinate is to be used as a map key, make sure it's immutable. Making all fields final is a good first step.
A.J. Côté wrote:Keep in mind the OP use case; he wants to shuffle the coordinate around. If coordinate had final final fields, he would be much more costly to change the coordinate because he would have to create a new object every time thus offsetting the gains because of the load on the garbage collector...
I was right when I said I had misspelt it
Rob Spoor wrote: . . .
1) The method is doubleToLongBits.
Doesn't += do a widening and narrowing conversion so the result is widened to a long and then narrowed to an int, so you can use it for a hash code method as long as it is deterministic and predictable. It will work without the cast.
2) The the cast isn't redundant. All of these operators produce longs since at least one argument is a long.
What makes you think I was writing readable code ? I was trying to show how unreadable the Joshua Bloch version of hashCode is. If you look in a book like Horstmann and Cornell, you find they have a much more readable version:-I had forgotten about Objects#hash; thank you for reminding me. I remember a long time ago you said you had written your own version of some of the Objects class' methods, as did lots of other people.
. . .
So your code a bit more readable:. . . .
Campbell Ritchie wrote:
Ted Schrey wrote:hmmmm.... thanks for all the input! Getting back to an ArrayList.... Would parsing the List with a for-each loop and when the object with specific coordinates are found, add that object to another toBeEmptied List work by emptying the second list? Would the object be deleted from the first list too, since both references are just pointing to the object? Am I understanding Object reference right?
Ted Schrey wrote:the grid size is open... determined by parameter. Same for number of Objects. For my current purpose, I'd keep grid between 10x10 and 25x25 with no more than a dozen Objects moving in random directions.