Vidis, dvakrat jsem to precetl, ale napsal jsem to presne tak, jak jsem vubec nechtel - znate to, hlavne to takhle nenapsat...
Presne tak = kolize a proto je dle meho nazoru ten equals v JavaDocu spravne. A z navrhu Object vypadavaji implementace jakou double hashing a jedna z mala (mozna jedina mozna) implementace mne vychazi seznam kolidujicich objectu, ktery se projede cely pomoci equals. a k tematu - v Javoveske impl chybi copy constructor - v STL by se volal pri put (vim jmenuje se to jinak) copy constructor, takze kontrakt by se dodrzel, ale jinak nez tazatel by chtel. On ??t, 2007-05-24 at 17:36 +0200, lukas wrote: > On Thu, 24 May 2007 17:10:03 +0200, Karel Tejnora wrote > > Opomenuti obecnych pravidel > > > > hashCode musi odpovidat chovani equals tj. A.equals(B)== true pak > > A.hashCode()==B.hashCode() a zaroven A.equals(B) == false pak > > A.hashCode()!=B.hashCode() > > Ta druha podminka prae platit nemusi. > > A.equals(B)==false neznamena, ze maji ruzne hashovani. > Tj. muzou existovat kolize :-) > Doporucuji precist nejakou teorii k hashovani :-) > > Lukas >
