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: 21 Mar 1995 11:50:59-GMT From: paj <paj@gec-mrc.co.uk> Subject: NICE-ESG-Libs Digest V1 #202 To: NICE-ESG-Libs@atlanta.twr.com > The major problem is that no one paid any attention to compatibility > with existing implementations. (At least this is the favorable > interpretation.) Passing the hashing proposals would break every > existing Eiffel system (at least every ISE Eiffel system, but I suspect > others as well). Not content with breaking existing systems, the > hashing proposal is perverse enough to reuse an existing feature name, > `hash_code', thus ensuring that thousands of users will have to write > dozens of `select' clauses! This is rather sadistic. I can see your point about compatibility: if we keep the existing "HASHABLE" class with an obsolete tag for backward compatibility, we will get name clashes in anything inheriting from HASHABLE. Its a pity you didn't point this out earlier: I would have voted NO had I realised that this was a problem. However, if as Bertrand suggests we create a new feature of ANY with a different name (I would suggest "hash_value" rather than "hashed"), then this will have no effect on HASHABLE and its descendants. Alternatively, we could move the universal hash function into its own little mixin class: e.g class HASH_ANY feature hash_value (obj: ANY); end; This is obviously a "magic" routine, in the sense that an implementation cannot be defined in Eiffel without invoking other magic routines (ANY.hash_value would also be magic of course). However this means that the semantics could be defined to invoke "hash_code" on any descendant of HASHABLE and use some vendor-specific default hashing function on all other classes. This is not terribly elegant, but I believe it is workable, and provides universal hashability without breaking any existing code (including classes that have a "hash_value" feature already). Paul. -- Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. | +44 245 473331 ext 3245 +-----------+-----------------------------------------+ Work: <paj@gec-mrc.co.uk> | You are lost in a twisty maze of little Home: <Paul@treetop.demon.co.uk> | standards, all different.
