This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: Re: Kinman Says this is Evil
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
To clarify, what Kinman -- and all the folks we've shown this to -- is saying he wouldn't expect the new item, whose "value" is equal, to be ignored. He'd expect the Set to replace the old object with the new one if they're identical.
I think we'd all agree that, for this case, in resolving conflicts you want to figure out which on is the "right" one and keep that one in the Set. That is, when a conflict arises between 2 things, one of those things is the thing you want, while the other is the thing you want to reject.
The question then becomes, how do you figure out which one is the "right" one?
On the one had you might expect the original item in the Set to be the "right" one. In some cases, that'd be true, e.g., you wouldn't want to overwrite a previously written value. On the other hand, you might expect the new one to be the "right" one. Also, in some cases that'd be true: the first one you put in could have been incorrect and you want to replace it with the correct one
So, obviously, that gets us no where. We might ask then, what Sets mean to people in respect to being a collection of values.
For me, when I call a command on a piece of code, I usually want it to what I tell it to. More importantly, I don't want it to "think" differently than I do. I want it to match my expectations exactly and not require me to double check those expectations.
In this case, our (Kinman and I's) expectation is that a Set cares about "physical" objects being added rather than the more ephemeral notion of the value that an object wraps being added. That is, sure, we want there to be only one entry for each value in the Set (otherwise, we'd use a List), but we want the containers of those values to matter. And, we want the newest container to replace the older container.
Now, one could justifiably get into a never ending argument about the finer points of equals, hashCode, and ==...and while I really like that kind of Effective Java chatter, I also really like getting code to do what I want how I want. Like I said, I don't want to the code to think for me: I want it to be obey my commands and expectations.
In another case, where you're concerned only with values, but not also their containers, how the Set is working is what you'd want: if the value you're adding already exists in the Set, no need to replace it with the same value. Rather, you shouldn't care what happens: all you want it to make sure that value exists in the Set, nevermind which object was used to get it in there.
I don't think either way could be said to be The Right Way: obviously, there's "the way it works in the JDK and as specified in the JavaDocs," but to put any sort of metaphysical value on that is silly. What's more important is to ferret out why and how either side thinks as they do, and that ferreting is hard to do if your looking for the absolute truth instead of how people are thinking.
Previous Topic
