NICE-ESG-Libs Digest Mon, 27 Mar 95 Volume 1 : Issue 208
Today's Topics:
Hashable etc.
NICE Eiffel Standards Group -- Library Committee Mailing List
To post to list:
NICE-ESG-Libs@atlanta.twr.com
To send mail to the Chairman of the committee:
NICE-ESG-Libs-chair@atlanta.twr.com
Administrative matters (sign up, unsubscribe, mail problems, etc):
NICE-ESG-Libs-request@atlanta.twr.com
Date: Mon, 27 Mar 95 13:05:50 EST
From: fhart@atlanta.twr.com (C. Frederick Hart)
Subject: Hashable etc.
To: NICE-ESG-Libs
Bertrand has stated that he desires to insure a proper transition
procedure for existing software regarding the proposed changes for
hashing. We are in complete agreement with this position.
Tower does not envision breaking any existing user code with these
proposals. We agree that the use of the feature name hash_code in
GENERAL is a problem and agree with Bertrand that hash_value would be
more appropriate.
In order to try to reach a compromise that addresses existing user
code and vendor concerns, let me propose the following transition
scenario.
1. HASHABLE remains part of PELKS but it is recommended that it be
marked as obsolete. Eiffel provides an excellent facility for
this :-).
2. `hash_value' is added to GENERAL. There is no relationship
between hash_value and hash_code (except that both are hashing
functions in a conceptual sense).
Existing code would work exactly as it does now (there may be
"obsolete" warnings issued when compiling it). New code would be
written to use hash_value instead of hash_code.
Changing existing code to use hash_value (if this is so desired by the
user) should be a simple matter of textual substitution of hash_value
for hash_code, elimination of inheritance clauses for HASHABLE and
possibly changing the effecting definitions of hash_code into
redefinitions of hash_value. Again, note that none of these changes
would strictly be necessary since existing code would compile and
execute exactly as it does now.
The advantage to the users seems significant. They get universal
hashing; they get it in a standard, portable way; and no existing code
is invalidated.
I welcome comments on these ideas and hope that we can reach a
compromise that all will find beneficial.
-- Fred Hart (fhart@atlanta.twr.com)
Tower Technology Corporation http://www.cm.cf.ac.uk/Tower/

|
|