Q: Would there be much breakage, if '==' with
reference types was redefined from the current:

http://www.digitalmars.com/d/expression.html#EqualExpression

" For class objects, equality is defined as the result of calling
  Object.opEquals(). If one or the other or both objects are null,
  an exception is raised."

  (where "an exception is raised" means: it will dereference null)

into:

" For class objects, the result is true if both references are null.
  and false if one and only one of the object references is null.
  Otherwise, it returns the result of calling Object.opEquals()."

  (where opEquals returns an int, not bool, for "efficiency reasons")


It's OK if null and calling Object.opCmp still throws...
(as in "it's an error to compare objects if one is null")

Equality and sortability are somewhat different concepts.
(Just as equality and identity, but that's another thread)


But it would be nice if at least "== null" did not throw ?

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d3g56v$26ov$1@digitaldaemon.com...
> Q: Would there be much breakage, if '==' with
> reference types was redefined from the current:
>
> http://www.digitalmars.com/d/expression.html#EqualExpression
>
> " For class objects, equality is defined as the result of calling
>   Object.opEquals(). If one or the other or both objects are null,
>   an exception is raised."
>
>   (where "an exception is raised" means: it will dereference null)
>
> into:
>
> " For class objects, the result is true if both references are
> null.
>   and false if one and only one of the object references is null.
>   Otherwise, it returns the result of calling Object.opEquals()."
>
>   (where opEquals returns an int, not bool, for "efficiency
> reasons")

Well, you only have to stay alive long enough to see everything come back around.

FYI I led a long and erudite but thoroughly ineffective campaign on this issue a couple of years ago.

Walter don't like it, and it ain't gonna happen.

:-(

Matthew wrote:

> Well, you only have to stay alive long enough to see everything come
> back around.

Yes, it's somewhat harder to search the D newsgroups
for rejected suggestions than what it is with Bugzilla...

Must confess I failed to check the *old* newsgroup. :-P

> FYI I led a long and erudite but thoroughly ineffective campaign on
> this issue a couple of years ago.

OK, that smells like the Boolean Wars all over again.

Found some references;
Thread: http://www.digitalmars.com/d/archives/12144.html
Walter: http://www.digitalmars.com/drn-bin/wwwnews?D/13854

> Walter don't like it, and it ain't gonna happen.

Good to know. That puts D one step below Java, even...

(In Java, this.equals(null) returns false always -
while null.equals(this) throws NullPointerException)

In D, this still needs to be implemented on the Unix
side, as the "Error" is only thrown on Windows DMD ?)

--anders


D - "Can you still love me, with these ugly warts ?"
I - "Why don't you just have them removed instead ?"

>> Well, you only have to stay alive long enough to see everything
>> come
>> back around.
>
> Yes, it's somewhat harder to search the D newsgroups
> for rejected suggestions than what it is with Bugzilla...
>
> Must confess I failed to check the *old* newsgroup. :-P

Don't worry about it. I never search. Who's got the bloody time?!

>> FYI I led a long and erudite but thoroughly ineffective campaign
>> on
>> this issue a couple of years ago.
>
> OK, that smells like the Boolean Wars all over again.
>
> Found some references;
> Thread: http://www.digitalmars.com/d/archives/12144.html
> Walter: http://www.digitalmars.com/drn-bin/wwwnews?D/13854

Yes, IIRC, it got the usual treatment: broad agreement by a majority, overruled by the minority.

>> Walter don't like it, and it ain't gonna happen.
>
> Good to know. That puts D one step below Java, even...

No argument from me there. (I can't say this out loud, since I'm now the class flamer, but it seems to me D's dying by a million cuts. Each one's pretty low on the grand scale, but they combine to give a poor impression. But, I can't say that, so don't worry about it.)

> (In Java, this.equals(null) returns false always -
> while null.equals(this) throws NullPointerException)
>
> In D, this still needs to be implemented on the Unix
> side, as the "Error" is only thrown on Windows DMD ?)

That's a big problem, but as with many other issues, consistency across platforms is less important than what's simple or easy to do.

> --anders
>
>
> D - "Can you still love me, with these ugly warts ?"
> I - "Why don't you just have them removed instead ?"

Careful. You'll get a rep.

Matthew wrote:

>>In D, this still needs to be implemented on the Unix
>>side, as the "Error" is only thrown on Windows DMD ?)
> 
> That's a big problem, but as with many other issues, consistency across platforms is less important than what's simple or easy to do.

I remember being somewhat surprised when it did not throw
an exception but segfaulted instead, but with the string
literals and the real type and the other platform-dependant
things I've stopped being too surprised about those things.

Fortunately, it's not much worse than what writing C/C++ is
when it comes to portability. Naturally, it's worse than Java.
(which amazingly enough is portable within their own platform,
you just have to watch out for bugs and for the major versions)

>>D - "Can you still love me, with these ugly warts ?"
>>I - "Why don't you just have them removed instead ?"
> 
> Careful. You'll get a rep.

I wouldn't be here if I didn't find D attractive anyways :-)
And I find it better to know it's dead, that to keep hoping.

That a feature is dead, that was. Not the language itself. Yet.

--anders

You might be amused by this quote from http://www.digitalmars.com/d/errors.html:

"
No errors get inadvertently ignored.
Error exceptions get handled one way or another. There is nothing
like a NULL pointer return indicating an error, followed by trying
to use that NULL pointer.
"

:-)


"Anders F Björklund" <afb@algonet.se> wrote in message news:d3g9j9$2apd$2@digitaldaemon.com...
> Matthew wrote:
>
>>>In D, this still needs to be implemented on the Unix
>>>side, as the "Error" is only thrown on Windows DMD ?)
>>
>> That's a big problem, but as with many other issues, consistency across platforms is less important than what's simple or easy to do.
>
> I remember being somewhat surprised when it did not throw an exception but segfaulted instead, but with the string literals and the real type and the other platform-dependant things I've stopped being too surprised about those things.
>
> Fortunately, it's not much worse than what writing C/C++ is when it comes to portability. Naturally, it's worse than Java. (which amazingly enough is portable within their own platform, you just have to watch out for bugs and for the major versions)
>
>>>D - "Can you still love me, with these ugly warts ?"
>>>I - "Why don't you just have them removed instead ?"
>>
>> Careful. You'll get a rep.
>
> I wouldn't be here if I didn't find D attractive anyways :-) And I find it better to know it's dead, that to keep hoping.
>
> That a feature is dead, that was. Not the language itself. Yet.
>
> --anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d3g56v$26ov$1@digitaldaemon.com...
> Q: Would there be much breakage, if '==' with
> reference types was redefined from the current:
>
> http://www.digitalmars.com/d/expression.html#EqualExpression
>
> " For class objects, equality is defined as the result of calling
>   Object.opEquals(). If one or the other or both objects are null,
>   an exception is raised."
>
>   (where "an exception is raised" means: it will dereference null)

It's interesting the doc says "one or the other" since it only errors if the left hand reference is null.

> into:
>
> " For class objects, the result is true if both references are null.
>   and false if one and only one of the object references is null.
>   Otherwise, it returns the result of calling Object.opEquals()."

The only downsides to this would be:
1) it would made opEquals different from opAdd and other overloadable
operators.
2) it decreases performance slightly since it has to do the null checks

I think the doc in that section needs to be replaced with the description in
http://www.digitalmars.com/d/operatoroverloading.html
"The expression (a == b) is rewritten as a.opEquals(b), and (a != b) is
rewritten as !a.opEquals(b). "

> It's OK if null and calling Object.opCmp still throws... (as in "it's an error to compare objects if one is null")
>
> Equality and sortability are somewhat different concepts. (Just as equality and identity, but that's another thread)

I think D approaches opEqual and opCmp as quite similar actually. More similar than equality and identity.

> But it would be nice if at least "== null" did not throw ?

yup - but I'm not holding my breath and with good tools the problem hopefully won't be too bad.

Ben Hinkle wrote:

>>" For class objects, equality is defined as the result of calling
>>  Object.opEquals(). If one or the other or both objects are null,
>>  an exception is raised."
>>
>>  (where "an exception is raised" means: it will dereference null)
> 
> It's interesting the doc says "one or the other" since it only errors if the
> left hand reference is null.

Well, it can segv with the right hand side too - with overloads...
But it is more certain segv with the left hand side null, true.

> The only downsides to this would be:
> 1) it would made opEquals different from opAdd and other overloadable
> operators.

This is a considerable downside, and thanks for bringing it up.

> 2) it decreases performance slightly since it has to do the null checks

I'm somehow suspecting this the main reason it's the way it is.

> I think the doc in that section needs to be replaced with the description in http://www.digitalmars.com/d/operatoroverloading.html
> "The expression (a == b) is rewritten as a.opEquals(b), and (a != b) is rewritten as !a.opEquals(b). "

At least the page doesn't say "eq" anymore (the old opEquals name)

Fixing the crossreferences and providing more detail would be nice.

>>Equality and sortability are somewhat different concepts.
>>(Just as equality and identity, but that's another thread)
> 
> I think D approaches opEqual and opCmp as quite similar actually. More similar than equality and identity.

It does, in fact it does so even more than Java does.

In Java, thing.equals(null) just returns false - but
thing.compareTo(null) throws a NullPointerException...

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Comparable.html

--anders

On Wed, 13 Apr 2005 09:13:38 +0200, Anders F Björklund <afb@algonet.se> wrote:
>> 2) it decreases performance slightly since it has to do the null checks
>
> I'm somehow suspecting this the main reason it's the way it is.

So can't it be treated similarly to array bounds checks? only done if not -release mode.

Regan

Regan Heath wrote:

>>> 2) it decreases performance slightly since it has to do the null checks
>>
>> I'm somehow suspecting this the main reason it's the way it is.
> 
> So can't it be treated similarly to array bounds checks? only done if not  -release mode.

I think Walter said he preferred the hardware to do the null pointer checks, even in the -release builds... (i.e. trap the hardware signal)

Thread: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14342
Walter: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14440

And redefining == with objects seem to be totally out of the question.
(i.e. making equality comparisions with null a legal/defined operation)

--anders