> Aw, sorry, I forgot about _that_! :)
>
> Hoping to be forgiven, I'll propose a "resembles" operator, which returns true if the pointers to two objects differ by less than a random quantity.

LOL

> (Please Matthew, don't write on CUJ about this, or D is dead).

I promise. :)

Riccardo De Agostini wrote:
> "Derek Parnell" <Derek.Parnell@No.Spam> ha scritto nel messaggio
> news:oprvilbpcryj5swd@news.digitalmars.com...
> 
>>Don't be silly, Riccardo. That would make code more readible and give us
>>less opportunities to have debug session.
> 
> 
> Aw, sorry, I forgot about _that_! :)
> 
> Hoping to be forgiven, I'll propose a "resembles" operator, which returns
> true if the pointers to two objects differ by less than a random quantity.
> 
> (Please Matthew, don't write on CUJ about this, or D is dead).
> 
> Ric

How about "was a". (which, logically, would erase both pointers, and return true if they were equal to some value (not necessarily each other))

 -- andy

In article <bk4292$1gi5$4@digitaldaemon.com>, Riccardo De Agostini wrote:
> "Farmer" <itsFarmer.@freenet.de> ha scritto nel messaggio news:Xns93F5249FA35FitsFarmer@63.105.9.61...
>> The meaning of == vs === is a big problem. For C++, Java and C# programmers the current semantics poses subtle differences as D references feel more like C++ pointers, Java references or C# references than  C++ references.
> 
> Furthermore, as you admit, D references resemble Java references and C# references. I'd add Delphi references and VB references to the list. Now, why should the semantics of ==, as applied to references, be changed to make it more similar to what C++ lets you do with pointers, in a language where references have a different meaning from C++?

Because of consistency with what the operator "=" does.

I pointed out in a post a few months ago that the semantics of operator
"=" (assignment) should IMHO resemble those of operator "==" (equality).

In D, operator "=" works as if it operated on pointers, and operator "==" works as if it operated on the actual objects.

In addition, equivalence can be overloaded, but assignment to my knowledge cannot.

I would say that either operator "==" and operator "=" should work as if on pointers or as if on the actual values (in which case both should be overloadable).

But not so that one does one thing and the other does something else.

Maybe I'm just too academic, seeking symmetry wherever I go. Admittedly, this is just a small detail in the big picture, and maybe the real world experience shows that things in fact should be as they are as they are now.

-Antti

"Andy Friesen" <andy@ikagames.com> ha scritto nel messaggio news:bk4ec3$20co$1@digitaldaemon.com...
> How about "was a". (which, logically, would erase both pointers, and
> return true if they were equal to some value (not necessarily each other))

:-)

With a little more help by the compiler, even a "is_likely_to_become", which checks for assignments to a reference in the next thirty lines of code or so, wouldn't hurt either...

Ric

"Antti Sykäri" <jsykari@gamma.hut.fi> ha scritto nel messaggio news:slrnbmbhho.lf.jsykari@pulu.hut.fi...
> Because of consistency with what the operator "=" does.

While I don't agree completely, at least your answer is about the language itself, with no "Language X** does it, so it must be the right way" issues.

> I would say that either operator "==" and operator "=" should work as if on pointers or as if on the actual values (in which case both should be overloadable).

So, since all other operators operate on the actual objects, "=" should, too. That's a good point, per se; but how do you initialize a reference, let alone copy it? We'd need another operator:

MyClass a, b;

a <- b; // Copy the reference so "a" and "b" reference the same object a = b; // Copy the object and make "a" a reference to the copy

Ric

> >
> >
> > I'm with Matthew on this one.  I think '==' needs to remain a value comparison and '===' should be changed to 'is'.
> >
> > The == and === debates originally happened a while back
> > in this forum.  I don't remember the all of the reasons
> > for the choice,  but one was for the syntax to remain consistent
> > with the syntax for arrays.  We wanted the comparison operators
> > to do element by element comparisons on arrays.  This is why you
> > can do convenient things like if(foo <= "fred") in D now.  == was
> > made a value comparison to remain consistent with the other
> > comparison operators.  It also made sense for the array and
> > object syntax to be consistent also so == was used as a value
> > comparison for objects too.  === was chosen to be the identity
> > comparison and as stated above I'd much prefer it to be 'is'.
> >
> > I think a number of issues with == would go away if it was implemented like this.
> >
> > if(a === b)
> > return true;
> > else if(a === null)
> > return false;
> > else if(b === null)
> > return false;
> > else // If a has an eq
> > return a.eq(b);
> >
> if == was implemented as that I believe ===/!== can be dropped the rare cases when you do want to compare that two objects are the same object would have to be ( &a == &b ) which is more visually obvious.
>
>

I think that == should compare object without checking for null and we should have another operator for "safe" comparison. That way it will be efficient for those cases where we know that object should not be nil...

But maybe a better solution would be to have ref modifier for references and the compiler optimize the full comparison above when he knows that either one or both arguments are not null... (not that the compiler would be able to suppose ref for local declaration that are known to bo non-null and cannot be modified externally). Note that the compiler might assumes reference if we called member function of the object...

And we could uses a ref operator (ref, * or @ are some
suggestions) when we want to tell the compile to assume valid reference

Something like:

a == b    // full comparision
*a == *b    // compare values
*a == b    // returns false if b is null; otherwise value comparison.
&a == &b // compare address

And using an operator to tell that we have a reference allows to check for null only on one side if the other size is known to be non null.

Alternatively, we can do values comparison by default and have a modifier for full comparison:

a == b // values comparison
@a == @b // full comparision
@a == b // returns false if a is null; otherwise values comparision


I would also prefer := for assignment as in Pascal and Delphi. This will essentially solve the problem of misusing = for == when we one to compare object and it would allows uses to have assignment in a condition without risk...

if (a == b) { }    // compare a et b
if (a := b) { }    // assign b to a and check a

And we will have another operator for reference assignment

a := b;    // value assignment
a $= b;  // ref assignment (or maybe @=)

"Matthew Wilson" <matthew@stlsoft.org> wrote in news:bjth3u$1n2l$1@digitaldaemon.com:

>> I think the meaning of == vs === should be swapped, it's just too subtle for all those C++ and Java programmers out there.
> 
> ... NO!
> 
> That would take it even further away from C++ and more towards Java. IMO that would be worse, but even from an unbiased pov it just exchanges one complication for another.
> 

You're right. It doesn't solve the problem but merely moves it to another corner. Personally, I can't remember that I have ever used the equals() function in Java - Okay, maybe for java.lang.String. But I need the identity operator quite often.


Farmer.

"Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in news:bk4290$1gi5$3@digitaldaemon.com:

> "Farmer" <itsFarmer.@freenet.de> ha scritto nel messaggio news:Xns93F534001C22itsFarmer@63.105.9.61...
>> This wouldn't make things clearer for C++ experienced programmers. They will just write "if (a == b)", because they are a not used to use the operator "is", some won't even know about it.
> 
> I assume (though I may be wrong) that an experienced C++ programmer who writes "MyClass a, b; if (a == b)" recognizes a and b as not being pointers, so he/she does not *expect* the == to compare pointers, but to call an overloaded "operator ==". If pointers are to be compared, the experienced C++ programmer (which I also assume to be, first of all, an experienced programmer) starts wordering, so he/she has a good RTFM session (or VTFS, Visit The Fantastic Site!) and discovers the "is" operator. Now it's like that, except that instead of "is" we have the rather confusing (when revising code) "===".
> 
> Ric

I'm not sure either, but me and obviously Mike Wynn expect that references
behave like pointers when we see "==". Maybe, this is due to our Java
experience and experienced C++ programmers with no Java/C# background
think differently.

"Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in news:bk4292$1gi5$4@digitaldaemon.com:

[snip]
> Furthermore, as you admit, D references resemble Java references and C# references. I'd add Delphi references and VB references to the list. Now, why should the semantics of ==, as applied to references, be changed to make it more similar to what C++ lets you do with pointers, in a language where references have a different meaning from C++?
> 
> Ric
> 

Consider that Java references act like pointers:

if (object == null)            //D meaning: if (object === null) if (object.equals(objectB))    //D meaning: if (object == objectB)


C# is actually quite special.

In essence it's evaluated like Patrick Down proposes right in this thread:
if(a === b)
return true;
else if(a === null)
return false;
else if(b === null)
return false;
else // If a has an eq
return a.eq(b);

But that means that C# programmers are also used to write:
if (object != null)

I don't know how Delphi references work, but I guess like C# references.



Farmer

"Farmer" <itsFarmer.@freenet.de> ha scritto nel messaggio news:Xns93FD4B286B3FitsFarmer@63.105.9.61...
> Consider that Java references act like pointers:
>
> if (object == null)            //D meaning: if (object === null)
> if (object.equals(objectB))    //D meaning: if (object == objectB)

I actually should be more careful when talking about languages I don't know.
:-)
Anyway, this looks more like a C++'ism forced into Java than a "real"
language feature to me.

> C# is actually quite special.
> [...]
> But that means that C# programmers are also used to write:
> if (object != null)

...but then does C# have pointers at all?

> I don't know how Delphi references work, but I guess like C# references.

I admit that Delphi references do work like Java references in this context, i.e. pointers are compared by the "=" operator. But Delphi has no operator overloading, so there can be no ambiguity.

Visual Basic, which has no pointers, has a "Is" operator to compare
references and, being there no operator overloading either, it obviously
compares pointers (yeah, where did you think the "is" operator idea came
from? My own little brain? No way ;-) ) This one, to me at least, looks like
the most elegant solution with regard to readability, and VB implements it
even if there would be no risk of ambiguity.
Yes, I know that _real_ programmers don't use VB... ;-)

Ric

--- Real programmers use COPY CON: <program_name>.EXE