I don't know why following. Can someone answer?

1. Object.opEquals(Object lhs, Object.rhs)

It seems to me that nobody uses it. Why it exists?

2. object.opEquals(TypeInfo lhs, TypeInfo rhs)

It might be used to hack for typeid(x) == typeid(y), but I'm not sure.
That is much ambiguous, and if it's really used, we should move it to
static TypeInfo.equals and explicitly use it by the name.

Kenji Hara

On Sat, 09 Mar 2013 16:28:50 +0100, kenji hara <k.hara.pg@gmail.com> wrote:

> I don't know why following. Can someone answer?
>
> 1. Object.opEquals(Object lhs, Object.rhs)
>
> It seems to me that nobody uses it. Why it exists?
>
> 2. object.opEquals(TypeInfo lhs, TypeInfo rhs)
>
> It might be used to hack for typeid(x) == typeid(y), but I'm not sure.
> That is much ambiguous, and if it's really used, we should move it to
> static TypeInfo.equals and explicitly use it by the name.
>
> Kenji Hara

I might be misremembering, but I seem to recall objA == objB is rewritten into Object.opEquals(objA, objB). Object.opEquals(Object lhs, Object rhs) then does the actual two-way comparison of objA.opEquals(objB) && objB.opEquals(objA).

-- 
Simen

On Saturday, March 09, 2013 21:00:07 Simen Kjærås wrote:
> On Sat, 09 Mar 2013 16:28:50 +0100, kenji hara <k.hara.pg@gmail.com> wrote:
> > I don't know why following. Can someone answer?
> > 
> > 1. Object.opEquals(Object lhs, Object.rhs)
> > 
> > It seems to me that nobody uses it. Why it exists?
> > 
> > 2. object.opEquals(TypeInfo lhs, TypeInfo rhs)
> > 
> > It might be used to hack for typeid(x) == typeid(y), but I'm not sure.
> > That is much ambiguous, and if it's really used, we should move it to
> > static TypeInfo.equals and explicitly use it by the name.
> > 
> > Kenji Hara
> 
> I might be misremembering, but I seem to recall objA == objB is rewritten
> into Object.opEquals(objA, objB). Object.opEquals(Object lhs, Object rhs)
> then does the actual two-way comparison of objA.opEquals(objB) &&
> objB.opEquals(objA).

I believe that that rewrite uses the free function opEquals in object_.d, and not the one on Object. To make matters even more bizarre, the one on Object isn't even static. I suspect that the one on Object can and should be axed. The way it's written is nonsensical, and AFAIK, it's never used.

Of course, the opEquals stuff does need to be revamped a bit anyway, since we'd decided that we want to move towards getting rid of opEquals, opCmp, toHash, and toString on Object, which in the case of opEquals means templatizing the opEquals free function and make it so that it doesn't use Object at all.

- Jonathan M Davis
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

2013/3/10 Jonathan M Davis <jmdavisProg@gmx.com>

> On Saturday, March 09, 2013 21:00:07 Simen Kjærås wrote:
> > On Sat, 09 Mar 2013 16:28:50 +0100, kenji hara <k.hara.pg@gmail.com>
> wrote:
> > > I don't know why following. Can someone answer?
> > >
> > > 1. Object.opEquals(Object lhs, Object.rhs)
> > >
> > > It seems to me that nobody uses it. Why it exists?
> > >
> > > 2. object.opEquals(TypeInfo lhs, TypeInfo rhs)
> > >
> > > It might be used to hack for typeid(x) == typeid(y), but I'm not sure.
> > > That is much ambiguous, and if it's really used, we should move it to
> > > static TypeInfo.equals and explicitly use it by the name.
> > >
> > > Kenji Hara
> >
> > I might be misremembering, but I seem to recall objA == objB is rewritten
> > into Object.opEquals(objA, objB). Object.opEquals(Object lhs, Object rhs)
> > then does the actual two-way comparison of objA.opEquals(objB) &&
> > objB.opEquals(objA).
>
> I believe that that rewrite uses the free function opEquals in object_.d,
> and
> not the one on Object. To make matters even more bizarre, the one on Object
> isn't even static. I suspect that the one on Object can and should be axed.
> The way it's written is nonsensical, and AFAIK, it's never used.
>
> Of course, the opEquals stuff does need to be revamped a bit anyway, since
> we'd
> decided that we want to move towards getting rid of opEquals, opCmp,
> toHash,
> and toString on Object, which in the case of opEquals means templatizing
> the
> opEquals free function and make it so that it doesn't use Object at all.
>

For #2,  I found this issue and commit.
http://d.puremagic.com/issues/show_bug.cgi?id=3917
https://github.com/D-Programming-Language/druntime/commit/8409adbbb6bde641bd2b852637016068d22c6756

As far as I see, object.opEquals(TypeInfo lhs, TypeInfo rhs) is redundant
and never used.

But for #1, I found the commit that was added, but I still cannot
understand why it was done.
https://github.com/D-Programming-Language/druntime/commit/1e7ddf0425050e4f184532ec1d99316c37a8b2eb

Kenji Hara