> On 29/08/2012 20:49, Eric Sosman allegedly wrote:
>> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>>> On 8/28/12 5:02 PM, markspace wrote:
>>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>> interface Hasher<Type> {
>>>>> int hash(Type t);
>> The difficulty is that an external Hasher would have no access to
>> private fields (...)
> This.
?
package deal;
public class ToBeHashed {
private int noGettersForMeThanks;
...
}
package express;
Hasher<ToBeHashed> hasher = new Hasher<ToBeHashed>() {
public int hashCode(ToBeHashed obj) {
// How do you obtain the value of
// obj.noGettersForMeThanks
// if that would be useful?
}
...
}
As an example of why a hasher might want access to a strictly-private
field, I offered String: How could a Hasher<String> (outside String
itself) use String's private `hash' element? (And before you say
"Give String a getHash() method," ponder what hashCode() does.)
On 8/30/2012 9:43 PM, Eric Sosman wrote:
> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
>> On 29/08/2012 20:49, Eric Sosman allegedly wrote:
>>> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>>>> On 8/28/12 5:02 PM, markspace wrote:
>>>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>>>
>>>>>> interface Hasher<Type> {
>>>>>> int hash(Type t);
>>>>>
>>> The difficulty is that an external Hasher would have no access to
>>> private fields (...)
>>
>> This.
>
> ?
>
> package deal;
> public class ToBeHashed {
> private int noGettersForMeThanks;
> ...
> }
>
> package express;
> Hasher<ToBeHashed> hasher = new Hasher<ToBeHashed>() {
> public int hashCode(ToBeHashed obj) {
> // How do you obtain the value of
> // obj.noGettersForMeThanks
> // if that would be useful?
> }
> ...
> }
>
> As an example of why a hasher might want access to a strictly-private
> field, I offered String: How could a Hasher<String> (outside String
> itself) use String's private `hash' element? (And before you say
> "Give String a getHash() method," ponder what hashCode() does.)
That is a very good point.
We could argue that equals should only depends on retrievable
information and so should hash.
But as you point out then there is the issue of caching
of hash values.
> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
>> On 29/08/2012 20:49, Eric Sosman allegedly wrote:
>>> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>>>> On 8/28/12 5:02 PM, markspace wrote:
>>>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>>> interface Hasher<Type> {
>>>>>> int hash(Type t);
>>> The difficulty is that an external Hasher would have no access to
>>> private fields (...)
>> This.
> ?
> package deal;
> public class ToBeHashed {
> private int noGettersForMeThanks;
> ...
> }
> package express;
> Hasher<ToBeHashed> hasher = new Hasher<ToBeHashed>() {
> public int hashCode(ToBeHashed obj) {
> // How do you obtain the value of
> // obj.noGettersForMeThanks
> // if that would be useful?
> }
> ...
> }
> As an example of why a hasher might want access to a strictly-private
> field, I offered String: How could a Hasher<String> (outside String
> itself) use String's private `hash' element? (And before you say
> "Give String a getHash() method," ponder what hashCode() does.)
Sorry for not being clear, Eric. I meant to emphasize how IMO that one
single point you mention is the decisive argument that settles the issue.
Imposing that classes should expose all information "relevant" (says
who??) to hashing is utter rubbish IMNSHO.
Eric Sosman <esos...@ieee-dot-org.invalid> writes:
> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
>> On 29/08/2012 20:49, Eric Sosman allegedly wrote:
>>> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>>>> On 8/28/12 5:02 PM, markspace wrote:
>>>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>>> interface Hasher<Type> {
>>>>>> int hash(Type t);
>>> The difficulty is that an external Hasher would have no access to
>>> private fields (...)
>> This.
> ?
> package deal;
> public class ToBeHashed {
> private int noGettersForMeThanks;
> ...
> }
> package express;
> Hasher<ToBeHashed> hasher = new Hasher<ToBeHashed>() {
> public int hashCode(ToBeHashed obj) {
> // How do you obtain the value of
> // obj.noGettersForMeThanks
> // if that would be useful?
> }
> ...
> }
> As an example of why a hasher might want access to a strictly-private
> field, I offered String: How could a Hasher<String> (outside String
> itself) use String's private `hash' element? (And before you say
> "Give String a getHash() method," ponder what hashCode() does.)
I have, and I don't see a problem. String can define hashCode(), and
hashCodeIgnoreCase(), and hashCode(Locale), if those turn out to be
useful things to do for that particular class (String is an exceptional
class in several ways). The objection is to building hashCode() into
the Object hierarchy and hard-coding its use in HashMap. A separate
interface would allow more flexibility.
Daniele Futtorovic <da.futt.n...@laposte-dot-net.invalid> writes:
> On 31/08/2012 03:43, Eric Sosman allegedly wrote:
>> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
>>> On 29/08/2012 20:49, Eric Sosman allegedly wrote:
>>>> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>>>>> On 8/28/12 5:02 PM, markspace wrote:
>>>>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>>>> interface Hasher<Type> {
>>>>>>> int hash(Type t);
>>>> The difficulty is that an external Hasher would have no access to
>>>> private fields (...)
>>> This.
>> ?
>> package deal;
>> public class ToBeHashed {
>> private int noGettersForMeThanks;
>> ...
>> }
>> package express;
>> Hasher<ToBeHashed> hasher = new Hasher<ToBeHashed>() {
>> public int hashCode(ToBeHashed obj) {
>> // How do you obtain the value of
>> // obj.noGettersForMeThanks
>> // if that would be useful?
>> }
>> ...
>> }
>> As an example of why a hasher might want access to a strictly-private
>> field, I offered String: How could a Hasher<String> (outside String
>> itself) use String's private `hash' element? (And before you say
>> "Give String a getHash() method," ponder what hashCode() does.)
> Sorry for not being clear, Eric. I meant to emphasize how IMO that one
> single point you mention is the decisive argument that settles the issue.
> Imposing that classes should expose all information "relevant" (says
> who??) to hashing is utter rubbish IMNSHO.
Objects that compare equal must hash to the same value. It follows that
if the hash function uses a value, so must the comparison method.
Relying on non-public information in the comparison method means
allowing two objects to compare non-equal even though there is no way,
using public information, to distinguish between them. I can honestly
say I've never done that or felt a need to do that.
>> On 31/08/2012 03:43, Eric Sosman allegedly wrote:
>>> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
>>> [...]
>>> As an example of why a hasher might want access to a strictly-private
>>> field, I offered String: [...]
>> Imposing that classes should expose all information "relevant" (says
>> who??) to hashing is utter rubbish IMNSHO.
> Objects that compare equal must hash to the same value. It follows that
> if the hash function uses a value, so must the comparison method.
Since java.lang.String had already been mentioned, it's sort
of too bad you didn't look at it before posting. Had you done so,
you'd have found that [1] hashCode() uses the private field `hash'
and [2] equals() does not.
> On 8/31/2012 11:08 AM, Jim Janney wrote:
>> Daniele Futtorovic <da.futt.n...@laposte-dot-net.invalid> writes:
>>> On 31/08/2012 03:43, Eric Sosman allegedly wrote:
>>>> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
>>>> [...]
>>>> As an example of why a hasher might want access to a strictly-private
>>>> field, I offered String: [...]
>>> Imposing that classes should expose all information "relevant" (says
>>> who??) to hashing is utter rubbish IMNSHO.
>> Objects that compare equal must hash to the same value. It follows that
>> if the hash function uses a value, so must the comparison method.
> Since java.lang.String had already been mentioned, it's sort
> of too bad you didn't look at it before posting. Had you done so,
> you'd have found that [1] hashCode() uses the private field `hash'
> and [2] equals() does not.
Well, Jim's wording may not be correct to the last bit but the message is still true: String's hash member just caches the hash code derived from the characters of the String. And obviously equals() must compare the characters. So basically both recur to the same underlying data.
Eric Sosman <esos...@ieee-dot-org.invalid> writes:
> On 8/31/2012 11:08 AM, Jim Janney wrote:
>> Daniele Futtorovic <da.futt.n...@laposte-dot-net.invalid> writes:
>>> On 31/08/2012 03:43, Eric Sosman allegedly wrote:
>>>> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
>>>> [...]
>>>> As an example of why a hasher might want access to a strictly-private
>>>> field, I offered String: [...]
>>> Imposing that classes should expose all information "relevant" (says
>>> who??) to hashing is utter rubbish IMNSHO.
>> Objects that compare equal must hash to the same value. It follows that
>> if the hash function uses a value, so must the comparison method.
> Since java.lang.String had already been mentioned, it's sort
> of too bad you didn't look at it before posting. Had you done so,
> you'd have found that [1] hashCode() uses the private field `hash'
> and [2] equals() does not.
If you want to play gotcha, it's sort of too bad you don't read this
newsgroup more often. I pointed out the use of the private field some
time ago, when we were discussing immutable classes.
If you'd rather argue on the actual issues, a cached result is not extra
information. The hashCode method in String doesn't return anything that
can't be computed from publically available information.
> The objection is to building hashCode() into
> the Object hierarchy and hard-coding its use in HashMap. A separate
> interface would allow more flexibility.
Absolutely! And if we add another method we don't even need IdentityHashMap any more. See my example here:
> Eric Sosman <esos...@ieee-dot-org.invalid> writes:
>[...]
>>> Objects that compare equal must hash to the same value. It follows that
>>> if the hash function uses a value, so must the comparison method.
>> Since java.lang.String had already been mentioned, it's sort
>> of too bad you didn't look at it before posting. Had you done so,
>> you'd have found that [1] hashCode() uses the private field `hash'
>> and [2] equals() does not.
> If you want to play gotcha, it's sort of too bad you don't read this
> newsgroup more often. I pointed out the use of the private field some
> time ago, when we were discussing immutable classes.
> If you'd rather argue on the actual issues, a cached result is not extra
> information. The hashCode method in String doesn't return anything that
> can't be computed from publically available information.
Right. Except hashCode() can arrange to compute the value
just once, while an external Hasher without access to the private
field would need to recompute it every single time. I never said
a Hasher could not compute a perfectly good hash code (for a sane
class, at any rate), just that it would have to forego benefits
that are available to an internal hashCode() method.
Are those benefits worth while? Sometimes yes, sometimes no.
Sun apparently believed that they were in fact worth while in the
case of java.lang.String (indeed, Bloch says String's hashCode()
received a lot of attention and went through multiple generations).
If you think caching String's hash is not worth the effort, I
encourage you to experiment with a variant rt.jar that omits the
cache, run some timings, and report the results.
To the other issue, about whether HashMap et al. should
have a constructor taking an externally-supplied Hasher as an
alternative to using the key's own hashCode() -- well, HashMap
is not a final class. Have at it!
(Nor, by the way, do I deny the potential utility of such
a hashed map. It could, for example, have been used to get
around the inadequacies of String.hashCode() in early Java ...)
Eric Sosman <esos...@ieee-dot-org.invalid> writes:
> On 8/31/2012 11:56 AM, Jim Janney wrote:
>> Eric Sosman <esos...@ieee-dot-org.invalid> writes:
>>[...]
>>>> Objects that compare equal must hash to the same value. It follows that
>>>> if the hash function uses a value, so must the comparison method.
>>> Since java.lang.String had already been mentioned, it's sort
>>> of too bad you didn't look at it before posting. Had you done so,
>>> you'd have found that [1] hashCode() uses the private field `hash'
>>> and [2] equals() does not.
>> If you want to play gotcha, it's sort of too bad you don't read this
>> newsgroup more often. I pointed out the use of the private field some
>> time ago, when we were discussing immutable classes.
>> If you'd rather argue on the actual issues, a cached result is not extra
>> information. The hashCode method in String doesn't return anything that
>> can't be computed from publically available information.
> Right. Except hashCode() can arrange to compute the value
> just once, while an external Hasher without access to the private
> field would need to recompute it every single time. I never said
> a Hasher could not compute a perfectly good hash code (for a sane
> class, at any rate), just that it would have to forego benefits
> that are available to an internal hashCode() method.
> Are those benefits worth while? Sometimes yes, sometimes no.
> Sun apparently believed that they were in fact worth while in the
> case of java.lang.String (indeed, Bloch says String's hashCode()
> received a lot of attention and went through multiple generations).
> If you think caching String's hash is not worth the effort, I
> encourage you to experiment with a variant rt.jar that omits the
> cache, run some timings, and report the results.
I certainly think that the performance gained from caching matters. But
your objection is without substance: once again, there is no reason why
String can't define a hashCode method for instances of Hasher to call.
No need to forego anything.
And String is very much an unusual case: it's final, immutable, and
frequently used as a hash key. Not many other classes will fall into
that category.
> >>> On 31/08/2012 03:43, Eric Sosman allegedly wrote:
> >>>> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
> >>>> [...]
> >>>> As an example of why a hasher might want access to a strictly-private
> >>>> field, I offered String: [...]
> >>> Imposing that classes should expose all information "relevant" (says
> >>> who??) to hashing is utter rubbish IMNSHO.
> >> Objects that compare equal must hash to the same value. It follows that
> >> if the hash function uses a value, so must the comparison method.
> > Since java.lang.String had already been mentioned, it's sort
> > of too bad you didn't look at it before posting. Had you done so,
> > you'd have found that [1] hashCode() uses the private field `hash'
> > and [2] equals() does not.
> If you want to play gotcha, it's sort of too bad you don't read this
> newsgroup more often. I pointed out the use of the private field some
> time ago, when we were discussing immutable classes.
> If you'd rather argue on the actual issues, a cached result is not extra
> information. The hashCode method in String doesn't return anything that
> can't be computed from publically available information.
But it does impose a need for the hash function to access a private method
so that it can return that value faster. Denying access to the private member
would kill that optimization, one that any type of immutable object might want to use.
That is the motivation for requiring access to private members.
Your anger is misplaced, as your recent post rejects that scenario, implying that the only reason to use private members in 'hashCode'-alikes is for calculation of the value.
Lew <lewbl...@gmail.com> writes:
> On Friday, August 31, 2012 8:56:50 AM UTC-7, Jim Janney wrote:
>> Eric Sosman <esos...@ieee-dot-org.invalid> writes:
>> >>> On 31/08/2012 03:43, Eric Sosman allegedly wrote:
>> >>>> On 8/30/2012 6:52 PM, Daniele Futtorovic wrote:
>> >>>> [...]
>> >>>> As an example of why a hasher might want access to a strictly-private
>> >>>> field, I offered String: [...]
>> >>> Imposing that classes should expose all information "relevant" (says
>> >>> who??) to hashing is utter rubbish IMNSHO.
>> >> Objects that compare equal must hash to the same value. It follows that
>> >> if the hash function uses a value, so must the comparison method.
>> > Since java.lang.String had already been mentioned, it's sort
>> > of too bad you didn't look at it before posting. Had you done so,
>> > you'd have found that [1] hashCode() uses the private field `hash'
>> > and [2] equals() does not.
>> If you want to play gotcha, it's sort of too bad you don't read this
>> newsgroup more often. I pointed out the use of the private field some
>> time ago, when we were discussing immutable classes.
>> If you'd rather argue on the actual issues, a cached result is not extra
>> information. The hashCode method in String doesn't return anything that
>> can't be computed from publically available information.
> But it does impose a need for the hash function to access a private method
> so that it can return that value faster. Denying access to the private member
> would kill that optimization, one that any type of immutable object might want > to use.
> That is the motivation for requiring access to private members.
> Your anger is misplaced, as your recent post rejects that scenario, implying > that the only reason to use private members in 'hashCode'-alikes is for > calculation of the value.
Once again: once again, there is no reason why String can't define a
hashCode method for instances of Hasher to call. No need to forego
anything.
Jim Janney wrote:
> Once again: once again, there is no reason why String can't define a
> hashCode method for instances of Hasher to call. No need to forego
> anything.
And, indeed, once again once again, 'String' has already provided such a method.
I don't see what the big to-do is about 'Object' having 'hashCode()' defined. It's just fine as an address proxy in the default implementation, never mind its use for hashing, and the override to provide value equality is exactly the effort needed for classes that need a "real" hash, only at least it's in the very class whose logic it is, rather than artificially separated into a separate 'Hasher' type.
So once again once again, the existing mechanism shows itself to be at worst not much worse than the proposal.
Also, once again once again, the hash must match the idea of equality for the type. I don't notice anyone arguing (yet) that 'equals()' should not be present in 'Object'. Best practices once again once again promote keeping 'equals()', 'hashCode()', 'compareTo()' (where present) and 'toString()' consistent with each other.
So once again once again once again once again we see the status quo being pretty much equivalent once again once again to the proposal once again.
Lew <lewbl...@gmail.com> writes:
> Jim Janney wrote:
>> Once again: once again, there is no reason why String can't define a
>> hashCode method for instances of Hasher to call. No need to forego
>> anything.
> And, indeed, once again once again, 'String' has already provided such a method.
> I don't see what the big to-do is about 'Object' having 'hashCode()' defined. It's > just fine as an address proxy in the default implementation, never mind its use > for hashing, and the override to provide value equality is exactly the effort needed > for classes that need a "real" hash, only at least it's in the very class whose logic > it is, rather than artificially separated into a separate 'Hasher' type.
> So once again once again, the existing mechanism shows itself to be at worst > not much worse than the proposal.
> Also, once again once again, the hash must match the idea of equality for the > type. I don't notice anyone arguing (yet) that 'equals()' should not be present > in 'Object'. Best practices once again once again promote keeping 'equals()', > 'hashCode()', 'compareTo()' (where present) and 'toString()' consistent with > each other.
> So once again once again once again once again we see the status quo > being pretty much equivalent once again once again to the proposal > once again.
Nothing in the hypothetical design prevents String, or any other class,
from defining a hashCode method, or multiple methods, with access to
private data or native code. Objections on this basis are therefore
without basis. I'm sorry if you find this confusing, but it's really
very simple.
It's also true that the majority of hash functions should depend only
on publically available data. This is not "rubbish" but a direct
consequence of how hashing works: objects that compare equal must hash
to the same value. In a small number of cases, using a private member
to cache the result of the hash calculation turns out, on average, to
be better than not cacheing it. This takes us back to the previous
point.
As you point out, the current design is not all that bad, but it's also
limiting and error prone. Limiting because a class can only have one
hash function when several might be useful: for instance, String has
equalsIgnoreCase but no hashCodeIgnoreCase. If you want to hash by
object identity for a class that overrides equals() and hashCode(), you
have to use a completely different implementation of the standard hash
map. Error prone because it takes concerns that should be kept together
(hashing is a concern of the map, not the object being hashed) and
divides them into otherwise unrelated classes. If you want to override
equals() for a class, how do you know where to look for hash maps that
might be affected?
Daniele Futtorovic <da.futt.n...@laposte-dot-net.invalid> writes:
> On 02/09/2012 19:54, Jim Janney allegedly wrote:
>> It's also true that the majority of hash functions should depend only
>> on publically available data. This is not "rubbish"
> Indeed, *that* is not. It's merely questionable.
> Mandating that *every* class conform to this scheme, however, is rubbish.
> All this discussion is essentially an invitation to throw access control
> to the four winds.
I was going to comment on this, but when I went to pick up another
"once again" they were fresh out of them... told me some crazy story
about a guy coming through in a big hurry and cleaning out the entire
stock. So you'll just have to imagine what I might have said :-)
