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: Tue, 28 Mar 1995 12:40:33 +1000 (EST) From: cmingins@insect.sd.monash.edu.au (Christine Mingins) Subject: Comment on HASHABLE To: NICE-ESG-Libs@atlanta.twr.com Jason Schroeder has asked me to circulate the following letter to the library committee: Christine ------------------------------------------------------------------------- Dear Fellow Eiffelists, If adding GENERAL:hash_code is so bad as to render existing code so unusable that such a modification deserves to be delayed even more, then could we see some examples please? Concrete code as well as abstract thinking should guide the hash_code debate. (Bertrand, are you questioning the entire motivation of GENERAL:hash_code or do you only bring up a technical problem involved with its implementaion?) Disagreeing with a necessary change because it might be impractical now only makes it more impractical later. Regardless of GENERAL:hash_code, HASHABLE is by far the worse solution. My reasoning: HASHABLE is not a good idea (not to mention other languages seem to be doing well by providing similar functionality at the language core: Lisp, C & C++, Smalltalk, Obj-C, Self to name a few). HASHABLE makes objects usable for hash tables. It is nonesense to require a different ancestory for classes just to place their intances in an efficient container! To push my point a bit, it would be like requiring all instances to be included in sets to have a parent ELEMENTARY with the feature "is_element_of(set:SET[ANY]):BOOLEAN". If HASHABLE must remain, then it is my observation that this forces the Eiffel community to use a certain data structure style. This is a bold move on behalf of all involved. This hampers data structure development and consistently places the burden of hashing-based-datastructure use on the writer of the "containee" class. In my opinion, this mixture of container and containee concerns is plainly wrong. If there is some hashing value functionality placed in class GENERAL, then the uneccessary conceptual and practical restriction is a non issue. (I mean, if there was supplied function somewhere: "canonical_object_hash_code(obj:ANY):INTEGER" which operated over any object, then it could be retro-fitted into class GENERAL at a later date but gives those needing the functionality something to work with today.) Jason Schroeder ___________________________________________________________________________
