[Rd] Fwd: Digest package - make digest generic?

[Dirk Eddelbuettel]

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.