There are bigger problems but:

Can please these:
    int opCmp(Object o);
    int opEquals(Object o);

be removed from Object!

No one uses them (i guess) (except AAs but i believe
this can be changed!) and they can cause a lot of problems!

Isn't it time to get rid of them?

On Sat, 07 Aug 2004 13:02:40 +0200, Ivan Senji wrote:

> There are bigger problems but:
> 
> Can please these:
>     int opCmp(Object o);
>     int opEquals(Object o);
> 
> be removed from Object!
> 
> No one uses them (i guess) (except AAs but i believe
> this can be changed!) and they can cause a lot of problems!
> 
> Isn't it time to get rid of them?

I use them!

How else can an array of objects be sorted?
what problems do they cause?

Ant

Ant schrieb:

>> Can please these:
>>     int opCmp(Object o);
>>     int opEquals(Object o);
>> 
>> be removed from Object!
>> 
>> No one uses them (i guess) (except AAs but i believe
>> this can be changed!) and they can cause a lot of problems!
>> 
>> Isn't it time to get rid of them?
> 
> I use them!

And why not?

> How else can an array of objects be sorted?

Have a look at Java's "Comparable" Interface. Their util.Arrays.sort() can use it. It works, but that's about it. Ugly to use, even uglier to implement. I think operator overloading is a much nicer approach than "Interfaces for everything".

> what problems do they cause?

People who still think in plain C get confused.

"Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.08.07.11.23.04.166202@yahoo.ca...
> On Sat, 07 Aug 2004 13:02:40 +0200, Ivan Senji wrote:
>
> > There are bigger problems but:
> >
> > Can please these:
> >     int opCmp(Object o);
> >     int opEquals(Object o);
> >
> > be removed from Object!
> >
> > No one uses them (i guess) (except AAs but i believe
> > this can be changed!) and they can cause a lot of problems!
> >
> > Isn't it time to get rid of them?
>
> I use them!

I use them too, but i wish that finally they are not automatically defined for every class!

> How else can an array of objects be sorted?
> what problems do they cause?

Problems are: I write a class or struct and by accident forget to declare these operators, and if i pass my type to a template using == or < on this type the compiler will not complain but use the default ones from object!

In the newer versions of DMD object doesn't define these operators, it only declares them, but this is still legal:

class A{}

A a,b;
a = new A;
b = new A;

if(a==b)...
if(a<b)...

IMO this shouldn't work because i didn't write these operators!

And additionally i may wan't my class objects to be incomparable, and this is not possible now.

> Ant
>

"Maik Zumstrull" <Maik.Zumstrull@gmx.de> wrote in message news:cf2h7n$1q95$1@digitaldaemon.com...
> Ant schrieb:
>
> >> Can please these:
> >>     int opCmp(Object o);
> >>     int opEquals(Object o);
> >>
> >> be removed from Object!
> >>
> >> No one uses them (i guess) (except AAs but i believe
> >> this can be changed!) and they can cause a lot of problems!
> >>
> >> Isn't it time to get rid of them?
> >
> > I use them!
>
> And why not?
>
> > How else can an array of objects be sorted?
>
> Have a look at Java's "Comparable" Interface. Their util.Arrays.sort() can use it. It works, but that's about it. Ugly to use, even uglier to implement. I think operator overloading is a much nicer approach than "Interfaces for everything".
>
> > what problems do they cause?
>
> People who still think in plain C get confused.

I am confused becouse i am thinking in 'plain' C++: (not C)
If i don't write an operator i don't want it to magically be there :(

On Sat, 07 Aug 2004 14:36:15 +0200, Ivan Senji wrote:

> "Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.08.07.11.23.04.166202@yahoo.ca...
>> On Sat, 07 Aug 2004 13:02:40 +0200, Ivan Senji wrote:
>>
>> > There are bigger problems but:
>> >
>> > Can please these:
>> >     int opCmp(Object o);
>> >     int opEquals(Object o);
>> >
>> > be removed from Object!
> 
> Problems are:

ahh... wasn't it called cmp(Object)
(and equals(Object)?)?

why did it change?

Ant

Ivan Senji wrote:

> "Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.08.07.11.23.04.166202@yahoo.ca...
>> On Sat, 07 Aug 2004 13:02:40 +0200, Ivan Senji wrote:
>>
>> > There are bigger problems but:
>> >
>> > Can please these:
>> >     int opCmp(Object o);
>> >     int opEquals(Object o);
>> >
>> > be removed from Object!
>> >
>> > No one uses them (i guess) (except AAs but i believe
>> > this can be changed!) and they can cause a lot of problems!
>> >
>> > Isn't it time to get rid of them?
>>
>> I use them!
> 
> I use them too, but i wish that finally they are not automatically defined for every class!
>
>> How else can an array of objects be sorted?
>> what problems do they cause?
> 
> Problems are: I write a class or struct and by accident forget to declare these operators, and if i pass my type to a template using == or < on this type the compiler will not complain but use the default ones from object!

That's exactly what I would expect it to do. One person's bug is another's
feature.

> In the newer versions of DMD object doesn't define these operators, it only declares them, but this is still legal:
> 
> class A{}
> 
> A a,b;
> a = new A;
> b = new A;
> 
> if(a==b)...
> if(a<b)...
> 
> IMO this shouldn't work because i didn't write these operators!

By that argument we shouldn't have anything in Object since you don't seem
to want to inherit any behavior automatically.

> And additionally i may wan't my class objects to be incomparable, and this is not possible now.

Then throw an exception in opCmp - sure it's run-time but incomparability is presumably very rare.

>> Ant
>>

i think walter added "op" to the front of all the operator functions to
avoid name conflicts (they used to be things like add(), mul() etc.  and now
they're opAdd(), opMul()).  personally i don't see what's wrong with
operator+() , but oh well.

Ivan Senji wrote:

> There are bigger problems but:
> 
> Can please these:
>     int opCmp(Object o);
>     int opEquals(Object o);
> 
> be removed from Object!
> 
> No one uses them (i guess) (except AAs but i believe
> this can be changed!) and they can cause a lot of problems!
> 
> Isn't it time to get rid of them?

Yes.

Anything Object defines, *everything* defines, and, when it's something as broad as this, it sucks.

The wost part is what exactly Object's behaviour is: the default opCmp effectively generates a random number for each object, and yields a comparison between those.  If this isn't abuse of overloaded operators, what is?

All it would take, as far as I can tell, is to change TypeInfoClass to compare hash codes instead of calling opCmp and opEquals.  Lucky for us, this means that Object can still be sorted in an array and used as an AA key while making comparison operators raise a compile time error. Everybody wins.

If nothing else, this would go a huge way toward disambiguating == and != from === and !==.  Using the former on most object references would be a compile error.

 -- andy

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cf2ibj$1qnr$1@digitaldaemon.com...
> And additionally i may wan't my class objects to be incomparable, and this is not possible now.

Just put an assert(0) in the opCmp() overload for your class.