vector.contains

java-programmer, vector.contains If I write a class and have a vector containing various instantiations of it,
and I want to see if the vector contains another,i.e.
theVector.contains(theClass)
What do I need to overload/write/tweak to make sure "contains" finds the
vector element if it is equal to the "theClass"?

Is there some method I add to myClass to make the contains work?

Thanks
Jeff Kish

java-programmer >> vector.contains On Thu, 22 Jul 2004 16:25:40 -0400, Jeff Kish <email***@***.com> wrote:

>If I write a class and have a vector containing various instantiations of it,
>and I want to see if the vector contains another,i.e.
>theVector.contains(theClass)
>What do I need to overload/write/tweak to make sure "contains" finds the
>vector element if it is equal to the "theClass"?
>
>Is there some method I add to myClass to make the contains work?
>
>Thanks
>Jeff Kish
I did some digging and found that contains relies on a "equals" function.
Do I just need to define my own for my class for contains to work?
Any guidelines here?
Thanks
Jeff Kish

java-programmer >> vector.contains Jeff Kish wrote:
> On Thu, 22 Jul 2004 16:25:40 -0400, Jeff Kish <email***@***.com> wrote:
>
>
>>If I write a class and have a vector containing various instantiations of it,
>>and I want to see if the vector contains another,i.e.
>>theVector.contains(theClass)
>>What do I need to overload/write/tweak to make sure "contains" finds the
>>vector element if it is equal to the "theClass"?
>>
>>Is there some method I add to myClass to make the contains work?
>>
>>Thanks
>>Jeff Kish
>
> I did some digging and found that contains relies on a "equals" function.
> Do I just need to define my own for my class for contains to work?
> Any guidelines here?
> Thanks
> Jeff Kish

Read up on the entry for equals() in the java.lang.Object class. It
should give you all the information you need. Be sure to also read up
on hashCode() at the same time... The two are related, and need to both
be considered together.

java-programmer >> vector.contains "Carl Howells" <email***@***.com> wrote in message
news:email***@***.com...
> Read up on the entry for equals() in the java.lang.Object class. It
> should give you all the information you need. Be sure to also read up
> on hashCode() at the same time... The two are related, and need to both
> be considered together.
>
Which brings up a point of interest. How do all of you handle the hashCode
method? Where I work, people almost always override equals and ignore
hashCode.

java-programmer >> vector.contains Ryan Stewart wrote:
> Which brings up a point of interest. How do all of you handle the hashCode
> method? Where I work, people almost always override equals and ignore
> hashCode.
>

Any object that overrides equals in a meaningful way SHOULD override
hashCode as well. If it doesn't, its implementation of hashCode is in
violation of the method's contract. Whether that has immediate
consequences depends on what is done with the object, but the potential
for problems in the future is present.

It's best to follow the basic rule that's given everywhere: If you
override equals, override hashCode to obey the method's contract, as
listed in the documentation for java.lang.Object.

java-programmer >> vector.contains On Thu, 22 Jul 2004 17:07:54 -0500, "Ryan Stewart"
<email***@***.com> wrote or quoted :

>Where I work, people almost always override equals and ignore
>hashCode.

Sun's docs say they must work in sync. Perhaps people have just
ignored the problem and empirically noticed most of the time they get
away with it. Not good from a maintenance point of view. It is sort
of like setting a mousetrap.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

java-programmer >> vector.contains In that class that you've created, you'll need to override the equals method
to define what conditions need to be met in order for two objects of this
class to be considered equal.

bort

"Jeff Kish" <email***@***.com> wrote in message
news:email***@***.com...
> On Thu, 22 Jul 2004 16:25:40 -0400, Jeff Kish <email***@***.com> wrote:
>
> >If I write a class and have a vector containing various instantiations
of it,
> >and I want to see if the vector contains another,i.e.
> >theVector.contains(theClass)
> >What do I need to overload/write/tweak to make sure "contains" finds the
> >vector element if it is equal to the "theClass"?
> >
> >Is there some method I add to myClass to make the contains work?
> >
> >Thanks
> >Jeff Kish
> I did some digging and found that contains relies on a "equals" function.
> Do I just need to define my own for my class for contains to work?
> Any guidelines here?
> Thanks
> Jeff Kish

java-programmer >> vector.contains On Thu, 22 Jul 2004 17:07:54 -0500, "Ryan Stewart" <email***@***.com>
wrote:

>"Carl Howells" <email***@***.com> wrote in message
>news:email***@***.com...
>> Read up on the entry for equals() in the java.lang.Object class. It
>> should give you all the information you need. Be sure to also read up
>> on hashCode() at the same time... The two are related, and need to both
>> be considered together.
>>
>Which brings up a point of interest. How do all of you handle the hashCode
>method? Where I work, people almost always override equals and ignore
>hashCode.
>
Can anyone give me a hint on exactly what to do with hashcode, being the sorry
rookie I feel like?

Thanks
Jeff Kish

java-programmer >> vector.contains On Thu, 22 Jul 2004 17:07:54 -0500, "Ryan Stewart" <email***@***.com>
wrote:

>"Carl Howells" <email***@***.com> wrote in message
>news:email***@***.com...
>> Read up on the entry for equals() in the java.lang.Object class. It
>> should give you all the information you need. Be sure to also read up
>> on hashCode() at the same time... The two are related, and need to both
>> be considered together.
>>
>Which brings up a point of interest. How do all of you handle the hashCode
>method? Where I work, people almost always override equals and ignore
>hashCode.
>
Somebody told me this:

"Overriding hashcode is only necessary if you are going to put the vector into
another container (primarily HashTables/HashMaps). It is usually used just to
provide a unique key for those types of structures"

is this inaccurate?

Thanks
Jeff Kish

java-programmer >> vector.contains On Fri, 23 Jul 2004 13:51:34 -0400, Jeff Kish <email***@***.com>
wrote or quoted :

>Can anyone give me a hint on exactly what to do with hashcode, being the sorry
>rookie I feel like?

for a start, read http://mindprod.com/jgloss/hashcodeh.html

This is general advice. If you want an introduction to something
vaguely concerning Java, look up the word in the Java glossary.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

java-programmer >> vector.contains On Fri, 23 Jul 2004 19:04:53 GMT, Roedy Green
<email***@***.com> wrote or quoted :

>>Can anyone give me a hint on exactly what to do with hashcode, being the sorry
>>rookie I feel like?
>
>for a start, read http://mindprod.com/jgloss/hashcodeh.html

try that again

http://mindprod.com/jgloss/hashcode.html

If these fail, usually it is a typo. Sometimes the problem is
singular/plural or verb/noun. If you are impatient, just look up the
word in the index at http://mindprod.com/jgloss/jgloss.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

java-programmer >> vector.contains Jeff Kish wrote:
> Somebody told me this:
>
> "Overriding hashcode is only necessary if you are going to put the vector into
> another container (primarily HashTables/HashMaps). It is usually used just to
> provide a unique key for those types of structures"
>
> is this inaccurate?

There may be some other esotheric uses for hashCode, but basically, it's correct.

But putting things into a HashMap is a very common occurrence. Even if you don't
do it now, it's quite probable that you (or someone else) will do it at some point
in the future and run into problems.

java-programmer >> vector.contains On Fri, 23 Jul 2004 19:20:34 GMT, Roedy Green <email***@***.com>
wrote:

>On Fri, 23 Jul 2004 19:04:53 GMT, Roedy Green
><email***@***.com> wrote or quoted :
>
>>>Can anyone give me a hint on exactly what to do with hashcode, being the sorry
>>>rookie I feel like?
>>
>>for a start, read http://mindprod.com/jgloss/hashcodeh.html
>
>try that again
>
>http://mindprod.com/jgloss/hashcode.html
>
>If these fail, usually it is a typo. Sometimes the problem is
>singular/plural or verb/noun. If you are impatient, just look up the
>word in the index at http://mindprod.com/jgloss/jgloss.html
Roedy, do you have any comments on my other followup post?
I have a class that has two strings. I'm not sure about your example i.e. why
the "17" is required.. is return string1.hashCode() + string2.hashCode()
reasonable, or do I absolutely need 17 + string1.hashCode() +
string2.hashCode()?

Thanks for your patience
Jeff Kish

java-programmer >> vector.contains On Fri, 23 Jul 2004 21:36:42 +0200, Michael Borgwardt
<email***@***.com> wrote:

>Jeff Kish wrote:
>> Somebody told me this:
>>
>> "Overriding hashcode is only necessary if you are going to put the vector into
>> another container (primarily HashTables/HashMaps). It is usually used just to
>> provide a unique key for those types of structures"
>>
>> is this inaccurate?
>
>There may be some other esotheric uses for hashCode, but basically, it's correct.
>
>But putting things into a HashMap is a very common occurrence. Even if you don't
>do it now, it's quite probable that you (or someone else) will do it at some point
>in the future and run into problems.
OK.. well if It is a private inner class used in only one method, then it is
reasonable?

thanks for the education!
Jeff Kish

java-programmer >> vector.contains Jeff Kish wrote:
> OK.. well if It is a private inner class used in only one method, then it is
> reasonable?

I suppose it's highly unlikely to turn into a problem in that case. Still,
at least add a little reminder comment.

java-programmer >> vector.contains On Fri, 23 Jul 2004 15:39:37 -0400, Jeff Kish <email***@***.com>
wrote or quoted :

>. I'm not sure about your example i.e. why
>the "17" is required.. is return string1.hashCode() + string2.hashCode()
>reasonable, or do I absolutely need 17 + string1.hashCode() +
>string2.hashCode()?

Hashcodes don't have to make sense, just be repeatable.

/**
* hashCode that combines two strings
* @return a hash code value on the pair of strings.
*/
public int hashCode()
{
int result = 17;
result = 37 * result + string1.hashCode();
result = 37 * result + string2.hashCode();
// etc for all fields in the object
return result;
}

There is nothing magic about 17 other than that is it prime, and prime
numbers tend to work well in any sort of scrambling.

You could abbreviate that to:

result = string1.hashCode();
result = 37 * result + string2.hashCode();
// etc for all fields in the object
return result;

I wrote it the way I did just to emphasise the parallelism.

I posted another combiner using XOR. See
http://mindprod.com/jgloss/hashcode.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

java-programmer >> vector.contains On Fri, 23 Jul 2004 15:39:37 -0400, Jeff Kish <email***@***.com>
wrote or quoted :

>Roedy, do you have any comments on my other followup post?

I decide which posts to answer largely by simplicity. If I'm pretty
sure I have grasped the question in one reading, I go for it. If not,
I leave it to someone else with more patience.

I'm looking for the easy questions that can be answered with a simple
link.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

java-programmer >> vector.contains On Fri, 23 Jul 2004 15:40:35 -0400, Jeff Kish <email***@***.com>
wrote or quoted :

>OK.. well if It is a private inner class used in only one method, then it is
>reasonable?

What you don't want to do is change the definition of equals without
fixing hashcode to match. A program that fails to do that is simply
wrong whether you use hashCode yourself or not.

If you don't redefine equals, the default hashCode will nearly always
suffice.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

java-programmer >> vector.contains Michael Borgwardt wrote:
> Jeff Kish wrote:
>
>> OK.. well if It is a private inner class used in only one method, then
>> it is
>> reasonable?
>
>
> I suppose it's highly unlikely to turn into a problem in that case. Still,
> at least add a little reminder comment.

The trouble with reminder comments is that you have to
be looking at them to be reminded. When the restrictions
they insist on are violated, the comments do nothing at all
to draw attention to themselves.

I'd suggest that Jeff go ahead and override hashCode().
If it's inconvenient to actually implement one, he could use

public int hashCode() {
// Nice reminder comment here ...
throw new UnsupportedOperationException();
}

Note that under Jeff's assumptions (i.e. "hashCode() is never
going to be called anyhow"), questions of efficiency are moot.
But if somebody manages to violate his assumptions, the code
will draw attention to itself quite effectively.

--
email***@***.com

java-programmer >> vector.contains "Roedy Green" <email***@***.com> wrote in message
news:email***@***.com...
> On Fri, 23 Jul 2004 15:40:35 -0400, Jeff Kish <email***@***.com>
> wrote or quoted :
>
> >OK.. well if It is a private inner class used in only one method, then it
is
> >reasonable?
>
> What you don't want to do is change the definition of equals without
> fixing hashcode to match. A program that fails to do that is simply
> wrong whether you use hashCode yourself or not.

In principle that's true, but when a class is a private inner class, then
some of these forward thinking recommendations can be relaxed. In this
example, if you're sure you're never going to use the class in a hash table
and so don't want to waste time implementing a correct hashCode() function,
but still want to catch the error on the off chance that somone later does
put it into a hash table, you can just override hashCode() as follows:

public int hashCode() {
throw new RuntimeException("hashCode() not implemented for this class");
}