Okay, if D works the same as C++, this should do the trick:

>       private int opCmp(Object o); // with no definition

It now becomes a LINK-TIME error if you try to call the function. Link-time is maybe not quite as good as compile-time, but it's certainly better than run-time.

Arcane Jill.

Ivan Senji wrote:

<snip>
> I thinks the problem would easilly go away if Object didn't have opCmp,
> then it would be a compile time error!
<snip>

Yes, we should fix this wart.  There's no point in inventing new language features to work around it.

http://www.digitalmars.com/drn-bin/wwwnews?D/26144

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/105

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <ca468u$r8t$1@digitaldaemon.com>, Stewart Gordon says...

>Yes, we should fix this wart.  There's no point in inventing new language features to work around it.


How about this. opCmp stays in Object, but instead of returning an int, it returns one of these:

>       enum CompareResult
>       {
>           LESS,
>           EQUAL,
>           GREATER,
>           NOT_COMPARABLE
>       }

The default implementation in Object returns CompareResult.NOT_COMPARABLE. That would make all objects essentially uncomparable UNLESS you overrode opCmp. As a beneficial side-effect, this would also enable you to REMOVE comparability in a derived class. For example, imagine we had a class Real that was comparable. You might want to derive a class Complex which was incomparable. With this scheme, you could do that.

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca4b6r$130m$1@digitaldaemon.com...
> In article <ca468u$r8t$1@digitaldaemon.com>, Stewart Gordon says...
>
> >Yes, we should fix this wart.  There's no point in inventing new language features to work around it.
>
>
> How about this. opCmp stays in Object, but instead of returning an int, it returns one of these:
>
> >       enum CompareResult
> >       {
> >           LESS,
> >           EQUAL,
> >           GREATER,
> >           NOT_COMPARABLE
> >       }
>
> The default implementation in Object returns CompareResult.NOT_COMPARABLE.
That
> would make all objects essentially uncomparable UNLESS you overrode opCmp.
As a
> beneficial side-effect, this would also enable you to REMOVE comparability
in a
> derived class. For example, imagine we had a class Real that was
comparable. You
> might want to derive a class Complex which was incomparable. With this
scheme,
> you could do that.

As you could also with disallowed plus more things.
opCmp isn't the only problem: there is also opEquals

class A{}
A a,b;

a==b; //is legal and is same as
a===b;

What sencedoes this have? I don't understand it!
If i wan't to compare for identity i will use === or is.



> Jill
>
>
>

Arcane Jill wrote:

<snip>
> The default implementation in Object returns CompareResult.NOT_COMPARABLE. That
> would make all objects essentially uncomparable UNLESS you overrode opCmp. As a
> beneficial side-effect, this would also enable you to REMOVE comparability in a
> derived class. For example, imagine we had a class Real that was comparable. You
> might want to derive a class Complex which was incomparable. With this scheme,
> you could do that.

A complex number isn't a kind of real number.

An array of reals is exactly that - an array of reals.  Reals being comparable makes it possible to do such things as sort and binary search.  If there is the odd complex number mixed in, then it isn't an array of reals anymore, even if the declaration confusingly says it is.

Subclasses are supposed to extend functionality, not remove functionality.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

On Tue, 08 Jun 2004 14:49:23 +0200, Ivan Senji wrote:
> class A{}
> A a,b;
> 
> a==b; //is legal and is same as
> a===b;
> 
> What sencedoes this have? I don't understand it!
> If i wan't to compare for identity i will use === or is.

They are not equivalent. The default implementation of opEquals does an identity comparison, but it can be overridden for equality comparison. This is really necessary because it's in a language which uses reference semantics for classes and allows operator overloading.

Mike Swieton
__
In the end, we will remember not the words of our enemies, but the silence of
our friends.
	- Martin Luther King, Jr.

"Mike Swieton" <mike@swieton.net> wrote in message news:pan.2004.06.08.14.36.15.590154@swieton.net...
> On Tue, 08 Jun 2004 14:49:23 +0200, Ivan Senji wrote:
> > class A{}
> > A a,b;
> >
> > a==b; //is legal and is same as
> > a===b;
> >
> > What sencedoes this have? I don't understand it!
> > If i wan't to compare for identity i will use === or is.
>
> They are not equivalent. The default implementation of opEquals does an identity comparison, but it can be overridden for equality comparison.
This is

Here is the point in the word CAN. If it isn't overridden then == and ===
are
doing the same thing. This seams to me like a big problem.

Let's say we have
some kind  of templetized container class (like set) that uses opEquals to
compare
objects. And the user uses set!(A) even though the class A doesn't implement
opEquals! The user may have forgotton about it, and the code still works but
not the way it should. Container uses identity comparison in opEquals and
i doubt there are cases where someone would want this? Are there?

with
class A{}
A a,b;
a==b; should be a compile time bug. If i really waqnted to do identitiy
check
i would have used === as i should!

> really necessary because it's in a language which uses reference semantics
for
> classes and allows operator overloading.

Can you please explain why is opEquals necessary to be in object? Maybe there is something i am missing.

>
> Mike Swieton
> __
> In the end, we will remember not the words of our enemies, but the silence
of
> our friends.
> - Martin Luther King, Jr.
>

Ivan Senji wrote:
<snip>
> This is
> 
> Here is the point in the word CAN. If it isn't overridden then == and === are doing the same thing. This seams to me like a big problem.
> 
> Let's say we have some kind  of templetized container class (like set) that uses opEquals to compare objects. And the user uses set!(A) even though the class A doesn't implement opEquals! The user may have forgotton about it, and the code still works but not the way it should. Container uses identity comparison in opEquals and i doubt there are cases where someone would want this? Are there?

<snip>

There are probably plenty of classes of which two instances cannot be equal in any meaningful sense.  For these, it only makes sense to compare the object references.  So it provides this default behaviour.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ca4vc7$27sg$1@digitaldaemon.com...
> Ivan Senji wrote:
> <snip>
> > This is
> >
> > Here is the point in the word CAN. If it isn't overridden then == and === are doing the same thing. This seams to me like a big problem.
> >
> > Let's say we have some kind  of templetized container class (like set) that uses opEquals to compare objects. And the user uses set!(A) even though the class A doesn't implement opEquals! The user may have forgotton about it, and the code still works but not the way it should. Container uses identity comparison in opEquals and i doubt there are cases where someone would want this? Are there?
>
> <snip>
>
> There are probably plenty of classes of which two instances cannot be equal in any meaningful sense.  For these, it only makes sense to compare the object references.  So it provides this default behaviour.

Exactly! But we are obviously thinking from the oposite sides :)
If 2 instances of a class cannot be compared i wan't a==b to be
illegal! What is === or "is" for? It is there to compare references
to instances for identity. I don't believe there can be a default behaviour
for == for classes that can't be compared!

> Stewart.
>
> --
> My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Ivan Senji wrote:
<snip>
>> There are probably plenty of classes of which two instances cannot be equal in any meaningful sense.  For these, it only makes sense to compare the object references.  So it provides this default behaviour.
> 
> Exactly! But we are obviously thinking from the oposite sides :) If 2 instances of a class cannot be compared i wan't a==b to be illegal! What is === or "is" for? It is there to compare references to instances for identity. I don't believe there can be a default behaviour for == for classes that can't be compared!

They can be compared.  They just compare unequal if they're not the same object.

This enables them to be used in container templates for such things as keys and searching.  There's no reason I can see for a class designer's wanting to prevent all users of the class from doing this.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.