Weird opEquals Problem

[H. S. Teoh]

On Wed, Feb 22, 2012 at 09:08:24PM -0500, Jonathan M Davis wrote:
[...]
> I don't remember _exactly_ how the free function version of opEquals lined out 
> (I believe that TDPL explains it),

Yes, TDPL lays out the entire function (slightly simplified).


> but it's something like
> 
> bool opEquals(Object a, Object b)
> {
>  if(a is b)
>  return true;
> 
>  if(a is null || b is null)
>  return false;

IIRC that line should read:

	if (a is null && b !is null || a !is null && b is null)

Somewhere in here is also:

	if (typeof(a)==typeof(b))
		return a.opEquals(b);

as a slightly optimization for the case when both are the same type.

>  return a.opEquals(b) && b.opEquals(a);
> }
> 
> This helps some of the problems you get with opEquals in other
> languages such as Java. It also checks for null, so you don't have to
> worry about a null object causing a segfault.

This is one of the little things that makes D shine. It's part of D's
motto of "the simplest thing to write should default to the safest, most
correct behaviour".

It jives with a principle I've always believed in when it comes to
programming languages (or any computer language): "Simple things should
be simple, and hard things should be possible." In this, D wins over
Java by both counts, because Java's verbosity violates "simple things
should be simple", and Java completely ruling out low-level operations
(e.g. to write a GC in Java) fails "hard things should be possible".


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't
deserve what you have now either.