On Wed, Feb 22, 2012 at 09:32:02PM -0500, Jonathan M Davis wrote:
> On Wednesday, February 22, 2012 18:22:59 H. S. Teoh wrote:
> > On Wed, Feb 22, 2012 at 09:08:24PM -0500, Jonathan M Davis wrote:
[...]
> > > 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)
>
> Why? If you have
>
> if(a is b)
>
> (which should be there for efficiency if nothing else), then you've
> already verified that they're not both null, so there's no point in
> checking that they aren't both null like you're doing there.
You could be right. I'm just writing from my memory of what TDPL says. I
could be wrong.
> If the actual implementation is doing what you suggest, it should be
> fixed.
Yes.
> > 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.
>
> Possibly, I don't recall for sure. It wouldn't surprise me.
Gah, we're both working from our possibly unreliable memories. So I
looked up the actual source code on github:
equals_t opEquals(Object lhs, Object rhs)
{
if (lhs is rhs)
return true;
if (lhs is null || rhs is null)
return false;
if (typeid(lhs) == typeid(rhs))
return lhs.opEquals(rhs);
return lhs.opEquals(rhs) &&
rhs.opEquals(lhs);
}
[...]
> > 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".
>
> As much as that may be true, his particular case is just a cut and
> dried case of D learning from Java's mistakes as opposed to the
> language being different due to different design goals.
Well, I was speaking from the viewpoint of a language user rather than a
language designer. :) I had been using C/C++ for about two decades, the
latter half of which saw me searching for (or perhaps inventing) a
better language with equivalent power/performance. Those years of
experience with C/C++ led me to hold rather high standards for my
"ideal" language, so it was rather pleasant to discover how much D
matched my requirements.
> C# managed to improved on Java on a number of counts even though it's
> a very similar language, simply because it was able to learn from
> Java's mistakes. Really, that's one of C++'s biggest problems. It was
> the first to do a lot of stuff, and the languages which followed
> learned from _its_ mistakes. D, being newer than all three of those
> languages, should have been able to improve upon them even if it
> didn't have all of the new and innovative features that it has.
Very true. Hindsight is always 20/20, as they say. Although C++ has
tried to fix itself over the years (esp. with C++11), it simply couldn't
overcome the fundamental flaws, as that would break too much existing
code.
> I do agree though that D strikes a much better balance than Java does.
[...]
I would argue D as a language is far superior to Java in many, many
ways. Even if the current implementation could do with some improvement.
;-)
T
--
MSDOS = MicroSoft's Denial Of Service
