equality & comparison by default (was Re: Too many 'self' in python.That's a big flaw in this language.)

[A.T.Hofkamp]

On 2007-06-28, Roy Smith <roy at panix.com> wrote:
> In article <slrnf87dbp.ga2.hat at se-162.se.wtb.tue.nl>,
>  "A.T.Hofkamp" <hat at se-162.se.wtb.tue.nl> wrote:
>
>> In object oriented programming, objects are representations of values, and the
>> system shouldn't care about how many instances there are of some value, just
>> like numbers in math. Every instance with a certain value is the same as every
>> other instance with the same value.
>
> Whether two things are equal depends on the context.  Is one $10 note equal 
> to another?  It depends.
>
> If the context is a bank teller making change, then yes, they are equal.  
> What's more, there are lots of sets of smaller notes which would be equally 
> fungible.
>
> If the context is a district attorney showing a specific $10 note to a jury 
> as evidence in a drug buy-and-bust case, they're not.  It's got to be 
> exactly that note, as proven by a recorded serial number.
>
> In object oriented programming, objects are representations of the real 
> world.  In one case, the $10 note represents some monetary value.  In 
> another, it represents a piece of physical evidence in a criminal trial.  
> Without knowing the context of how the objects are going to be used, it's 
> really not possible to know how __eq__() should be defined.

I can see your point, but am not sure I agree. The problem is that OO uses
models tailored to an application, ie the model changes with each application.

In a bank teller application, one would probably not model the serial number,
just the notion of $10 notes would be enough, as in "Note(value)". The contents
of a cash register would then for example be a dictionary of Note() objects to
a count. You can merge two of such dictionaries, where the 'value' data of the
Note objects would be the equivalence notion.

In an evidence application one **would** record the serial number, since it is
a relevant distinguishing feature between notes, ie one would model Note(value,
serialnumber).
In this application the combination of value and serial number together defines
equivalence.

However, also in this situation we use values of the model for equivalence. If
we have a data base that relates evidence to storage location, and we would
like to know where a particular note was stored, we would compare Note objects
with each other based in the combination of value and serial number, not on
their id()'s.
 

> You tell me.  This is really just the "does 1 == (1 + 0j)" question in 
> disguise.  There's reasonable arguments to be made on both sides, but there 
> is no one true answer.  It depends on what you're doing.

While we don't agree on how OO programming handles equality (and it may well be
that there are multiple interpretations possible), wouldn't your argument also
not lead to the conclusion that it is better not to have a pre-defined __eq__
method?


Albert