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: Fri, 24 Mar 95 17:34:51 PST From: bertrand@vienna.eiffel.com (Bertrand Meyer) Subject: Hashable etc. To: nice.lib@vienna.eiffel.com Copy to: From: Bertrand Meyer Mailer: BOOM Dear colleagues: In (brief) response to Fred Hart, my colleagues and I have no problem with removing either or both of class HASHABLE and the precondition `is_hashable' if these changes are done properly, i.e. with the right timing and the proper transition procedure for existing software. In particular, what makes the problem non-trivial is that, quite naturally, someone who has been using HASHABLE and is now using the new `hash_value' (thanks for the suggested name, Paul) will want `hash_code' of HASHABLE to use `hash_value'. Take a look at the problem and you will see that it is non-trivial (repeated inheritance conflicts etc.), although I am sure an acceptable solution can be found if the needs of current users are accorded proper consideration. It is interesting then to compare my reaction with that of Paul Johnson. Paul, who voted yes, then wrote that if he had known of the compatibility problems he would have voted no. I voted no, but clearly I could vote yes in the future if the transition concerns are properly addressed. So in this case the disagreement that my ISE colleagues I have with Tower is not really technical; it has to do with the standards process. We think the first step in standardizing should be to consolidate what already exists and foster consensus. A standard that would immediately and irrecoverably break a considerable part of existing Eiffel software is worse than no standard. Once we have a consensus interoperability basis, we will all be in a much better situation to discuss changes and extensions, making sure that we chart a smooth transition whenever needed. -- BM
