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/