Message-ID: <18197.29989.476315.453783@ron.nulle.part>
Date: 2007-10-17T02:36:21Z
From: Dirk Eddelbuettel
Subject: Digest package - make digest generic?
In-Reply-To: <59d7961d0710161810r5e3c8f10o2155dffa47ee20ac@mail.gmail.com>
On 16 October 2007 at 18:10, Henrik Bengtsson wrote:
| if there is a need for a digest0(), which there seems to be, we should
| have one, but we should find a better name.
|
| A better approach may be to keep digest() as is and introduce
Agreed. It's better to keep the existing name and functionality.
| hashCode() for the feature Hadley requested, e.g.
|
| hashCode <- function(...) UseMethod("hashCode");
| hashCode.default <- function(...) digest(...);
|
| Personally, I think hashCode() is a more descriptive term of the
| value/outcome whereas digest() describes the action. Of course, some
| of the arguments of digest() should be excluded from hashCode(), but
| the above gives you the idea.
Not sure I like the 'hashCode' name all that much. How about some verbNoun
combination like 'createHash' ?
| That would make the distinction clear, and it is very much in line how
| Java is doing it (sorry Dylan folks). I think the Java got a useful
| setup with its hashCode() & equals() methods. If you want the
| details, here is one reference:
|
| http://www.geocities.com/technofundo/tech/java/equalhash.html
|
| but the short story is that <quote>two objects that are "equal" must
| produce the same hash code as long as they are equal, however unequal
| objects need not produce distinct hash codes.</quote>. The equals()
| relationship should be reflexive, symmetric, transitive, consistent.
| For details, see above URL. These rules are very useful, but requires
| quite a bit of effort from the developer/maintainer in order to keep
| it up to date and valid.
Yes, I am not sure I can guarantee that. We can always try, though.
Thanks for the follow-up!
Dirk
--
Three out of two people have difficulties with fractions.