Re: is_equal of HASHABLE

Frank Boehme wrote:
> Hi,
> 
> This is certainly not important but I suggest to add a postcondition to
> is_equal in HASHABLE as done below:
> 
> 
> 
> deferred class HASHABLE
> 
> insert ANY
>     redefine is_equal
>     end
> 
> feature {ANY}
> 
>     is_equal(other: like Current): BOOLEAN is
>         do
> 	    Result := Precursor(other)
>         ensure then
> 	    Result implies hash_code = other.hash_code
>         end
> ...
> 
> 
> This is because is_equal is not frozen and one might in error redefine
> it such that equal objects have different hash_codes which breaks
> everything that is based on hashing (SETs, DICTIONARYs,...)
As said previously, I like the suggested ensure assertion and
I presume that, now, we all agree on that point.
Philippe Ribet has pointed out a possible drawback of your
proposal: we now have two concrete bodies (one inherited from
ANY and one in HASHABLE).
Knowing that HASHABLE is very often used together with multiple 
inheritance... it may bothering for people to undefine the good
one in order to select the best body.
So, the idea I have is to propose to redefine is_equal as
deferred :-)

Here is the new proposal to be discussed / tested:

----------------------------------------
deferred class HASHABLE
insert ANY
      redefine is_equal
      end
feature {ANY}

      is_equal(other: like Current): BOOLEAN is
          deferred
          ensure then
  	    Result implies hash_code = other.hash_code
          end
  ...



Stay tuned.
-- 
--------------------------------------------------------------
[email protected] -- IUT (Nancy 2) -- INRIA Lorraine
http://SmartEiffel.loria.fr  --  The GNU Eiffel Compiler
POST: Loria, B.P. 239,54506 Vandoeuvre les Nancy Cedex, FRANCE
Voice:+33 0383913140 Mobile: +33 0665362381 Fax:+33 0383581701