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: Wed, 22 Mar 95 22:11:52 EST From: fhart@atlanta.twr.com (C. Frederick Hart) Subject: Bertrand's comments on the recent proposals To: nice-esg-libs I wish to make a quick response to the technical content of Bertrand's last posting. The concern that simply moving `hash_code' to GENERAL can cause problems for existing Eiffel code is valid. I wish this observation had been made in time for the proposal to have been modified since there is an apparently easy fix. Simply leave HASHABLE as it is and add a new hashing feature to GENERAL. I like Paul's suggestion of `hash_value'. No existing software is invalidated and users who need universal hashing get it in a standard way. The difficulty with users adding a hashing function to ANY is that it is unreasonable to expect that users could write efficient and portable hashing functions that are applicable to all objects. Such functions would likely have to make use of runtime information that is peculiar to each compiler, and there is no guarantee that such information is available from every vendor. Bertrand gave no technical arguments for why he voted to prevent default values from being hashable. No other general purpose implementation of hashing of which I am aware has this restriction. I cannot see that removing such an obscure restriction places an undue burden on the ISE libraries especially since removing the restriction should be trivial. This seems in line with Bertrand's and Eiffel's philosophy of making life hard on the compiler writers and not the users. Bertrand asserts that we should omit PART_COMPARABLE on the theory that it is unnecessary. Nevertheless, ISE, SIG, and Tower all have such a class in their current kernels. All seem to find it useful. The operators <, >, etc that are found in COMPARABLE have their natural seeds in PART_COMPARABLE. Why not just standardize this class. As Bertrand says, "let's codify existing practice". COMPARABLE and PART_COMPARABLE describe mathematical "orderings". The other mathematical terms that Bertrand refers to: "transitive relations, preorders, symmetric relations, reflexive relations" do not describe orderings and are not germane to this discussion. As far as Bertrand's objection to COMPARABLE goes, he refers to some discussions with Michael Schweitzer last year. Since I was not party to those discussions I can not evaluate the rationale he used. The reasons for including order_equal in Paul's and Tower's proposal were outlined in detail in my original proposal. Nothing Bertrand has posted has negated those arguments. -- Fred Hart (fhart@atlanta.twr.com) Tower Technology Corporation http://www.cm.cf.ac.uk/Tower/
