Re: Comparing DS_HASH_TABLE objects

Hello Bernd,

nice to read your comment and learning something about what has been
discussed for ECMA Eiffel. I am very interested about anything in that area.

Let me comment on some of your statements.

The notion of equality has puzzled me since the beginning. But I come to
different conclusions than you. Let me state me my opinion and the reasons.

A reference entity represents an object. There is no need to dereference
like in C. All feature calls etc. give you the impression that anything
you do with a reference entity you do on the object and not on the
address. Therefore I come to the conclusion that a reference entity in
Eiffel represents the object and not the address (even if more than one
entity can represent the same object).

This breaks then it comes to the "=" operator. Then the operator acts on
the address and not on the object. That's strange.

If you make a class a descendant of COMPARABLE the subject gets even
stranger. You define the operators "<=" and ">=" which in reality mean
"<~" and ">~". Do you want to recommend not to use comparisons on
reference objects? Then how do you implement a sorted binary tree?

The same applies to hashing. The hash is calculated from the object and
needs object equality to be consistent. Think of a
HASH_TABLE[SOME_TYPE,STRING]. Do you want to hash the address of the
string or the content?

I am glad to hear that removing is_equal and copy from ANY has at least
been considered. Yes, they can be defined in a different class EQUALITY
and every class which wants the features can inherit from that class
(similay to COMPARABLE).

The reason you gave for not having done that is not convincing (at least
not to me). Any expanded which is not a descendant from EQUALITY cannot
be assigned by ":=" and compared by "=". What is the problem? Any type
which is not a descendant from COMPARABLE cannot be compared by "<=",
"<", etc. Nobody complains about that. I admit that the overwhelming
majority of expanded classes will inherit from EQUALITY (otherwise they
are not very useful if you cannot even assign). Therefore it could be
enforced by a language  rule that expanded types must be descendants of
EQUALITY.

But regardless whether is_equal is in ANY or not, many classes will have
is_equal defined because the notion of equality makes sense for most of
the classes/types and the features are needed.

I even go so far that the default version of is_equal shall be the
"deep" version. You can always argue that everybody who wants that can
define it that way. But default version should be chosen in a way that
they reflect the most natural way of thinking. An object having
references usually "represents" the whole cloud of objects it can reach.
Therefore the most natural notion of equality in that case is the deep
one and the flat one is the more artificial.

The GOBO lib has chosen a very consistent workaround these problems. It
does not use the language defined equality. You have to provide
XXX_COMPARERs to the containers. Good choice given the current state of
affairs!

Anyhow, I am glad to read about different opinions. It gives me a chance
to think more thoroughly about my own position (and sometimes to change
it ;-) ). So I would be glad to read more "challenges".

Helmut



Bernd Schoeller wrote:
> Hi everybody,
> 
> Had to catch up to this interesting discussion. Just want to add my 5  
> cents:
> 
> Eric is perfectly right that there are many ways to compare objects  
> and is_equal is just one of them. "Pure" object-orientation has just a  
> single native equality and that is reference equality. All other  
> equalities are artificial.
> 
> There was a discussion on removing is_equal from ANY in ECMA. The  
> reason it was left in (including the cat-call prone signature) is:  
> expanded types.
> 
> IMHO, 'is_equal' and 'copy' are both in ANY for the only(!) reason  
> that they are needed when the semantics of ":=" and "=" changes for  
> expanded types. Reference assignment and comparison are not working  
> anymore in that case.
> 
> Being aware of this, using 'is_equal' and 'copy' should be avoided  
> whenever you are working with reference objects. Unfortunately, this  
> fact is ignored in most Eiffel libraries. That '~' is defined in terms  
> of 'is_equal' in ECMA continues this mess. I think using ~ should be  
> avoided, too.
> 
> Bernd
> 
> On Jun 5, 2009, at 2:35 AM, Helmut Brandl wrote:
> 
>>
>> Peter Gummer wrote:
>>> Helmut Brandl wrote:
>>>> Exactly. I would like to have to most natural operator to express  
>> object
>>>> equality. And that is "=". I guess in the majority of the cases  
>> the user
>>>> wants to test object equality and not reference equality.
>>>>
>>>> But this is a theoretical wish. Nobody will accept such a  
>> discussion.
>>>> The argument with backward compatibility kills everything in that  
>> direction.
>>> True, but it's fun to dream of what Eiffel++ might look like ;-)
>> I am glad that there a persons out thinking about beyond ECMA.
>>
>>> Following this logic through, we should change the assignment  
>> operator
>>> to perform copy semantics for reference types, so that a := b would
>>> perform what we today write as a := b.twin. This is becoming a bit  
>> scary.
>>
>> I am not sure if I would go so far. Why do you use a := b.twin?  
>> Usually
>> this is not necessary.
>>
>> But I would use is_deep_equal and deep_twin as a default for is_equal
>> and twin. The flat twin is not very meaningful in most of the cases.
>>
>> Helmut
>>
>>
> --
> Bernd Schoeller, PhD, CTO, Partner
> Comerge AG, Technoparkstrasse 1, CH-8055 Zurich, www.comerge.net
> 
> 
> 
> 
> 
> ------------------------------------
> 
> To Post a message, send it to:   [email protected]
> To Unsubscribe, send a blank message to: [email protected]! Groups Links
> 
> 
> 


------------------------------------

To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected]! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/gobo-eiffel/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/gobo-eiffel/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/