Yet again I've run foul of the `obj == other` being obj.cmp( other )
not only was `other` null which I would assume is a bit of an odd thing to, but I still don't get the reason behind ==/!= treating the object by value and not reference.

first, D objects are not C++ references that behave in every other respect as Java object, and as `->` === `.` they are C pointers.

second, 90% of my compares are ===/!==

third, its only objects that have two equality comparitors
int a, b => a == b === a === b ?confused yet?

fourth, I hate the subtle difference in visual reprosentation for such a huge difference in behaviour.

fifth, whats wrong with a.equals( b ) or *a == *b (could be *a == b or $a == b you only need to mark the lhs as being a value not an object, which fits with operator cmp (has an object as a param))

is anyone else frustrated by the comparison operators or is it just me having a bad day 'cos I can't write
if ( !(v = cast(Var)obj) ) {... }
so change them all to
if ( (v = cast(Var)obj) == null ) {... }
and it fell over and I had to go in search of all my == to see which should be === and which should be ==

also
if ( foo === "mark" ) { ... } is almost an error
so if == was as I'd like
if ( foo == "mark" ) { ... } would not be valid
even if you have done foo = "mark"; before as that is relying on constant merging (unless that is in the D compiler spec)
even with const char[] MARK = "mark"; if( foo == MARK ) D arrays are not const so although foo = MARK is not foo = MARK.dup how often is this used ?
isn't if ( $foo == "mark" ) { ... } more obvious that you are saying
the value of foo is "mark"
or `if ( $foo == fred ) { ... }` if the value of foo is the same as fred
`if ( foo == fred ) { ... }` if foo is fred

Mike Wynn wrote:
> Yet again I've run foul of the `obj == other` being obj.cmp( other )
> not only was `other` null which I would assume is a bit of an odd thing to, but I still don't get the reason behind ==/!= treating the object by value and not reference.

I agree.  The simplest solution is to simply remove the overload for == from the Object class, thereby making such a comparison a compile time error.

 -- andy

> is anyone else frustrated by the comparison operators or is it just me

I've got an article in this month's CUJ - "Identity and Equality: Syntax and Semantics" - which looks at this issue for C++, C#, D, Java, J#, Python and VB.NET. I was genuinely surprised to realise as I was writing it that C++ and Python were the only two with sensible ways of doing evaluating the identity and equality of variables, with D and Java pretty brain-dead, and C# +vely stupid. (I'm not going to debate it here - my entire argument is in the article.)

I've been expecting to be tossed from this ng for the last week, but it appears there are very few CUJ readers that inhabit it. Don't really know whether that's a good or a bad thing overall ...

"Mike Wynn" <mike@l8night.co.uk> ha scritto nel messaggio news:bjrf0m$1rpd$1@digitaldaemon.com...

(hmmm, this time I'm gonna get shot... :-) )

How about getting rid of === and !== and having a "is" operator which checks for equality of pointers?

if (a is b) printf("a points to the same object as b\n");

if (a == b) printf("a.eq(b) returned true\n");

Ric

> (hmmm, this time I'm gonna get shot... :-) )
>
> How about getting rid of === and !== and having a "is" operator which
checks
> for equality of pointers?

That's what I would suggest. You'll never get it swallowed, though.

Riccardo De Agostini wrote:
> "Mike Wynn" <mike@l8night.co.uk> ha scritto nel messaggio
> news:bjrf0m$1rpd$1@digitaldaemon.com...
> 
> (hmmm, this time I'm gonna get shot... :-) )
> 
> How about getting rid of === and !== and having a "is" operator which checks
> for equality of pointers?

WHY!! that's what is causings the problems == being .cmp not &a == &b
do you realy use == that much ?

> 
> if (a is b) printf("a points to the same object as b\n");

 if (a == b) printf("a points to the same object as b\n");

> 
> if (a == b) printf("a.eq(b) returned true\n");

 if (a eq b) printf("a.eq(b) returned true\n");

> 
> Ric
> 
> 

"Mike Wynn" <mike@l8night.co.uk> ha scritto nel messaggio news:bjs6pm$2tok$1@digitaldaemon.com...
> Riccardo De Agostini wrote:
> > "Mike Wynn" <mike@l8night.co.uk> ha scritto nel messaggio news:bjrf0m$1rpd$1@digitaldaemon.com...
> WHY!! that's what is causings the problems == being .cmp not &a == &b

I'm sorry but I think the problem is not with the meaning of == and !=. I feel they act as they should, i.e. on objects as opposed to pointers. All other operators (with the exception of === and !===, about whom I share your feelings about the excessive visual similarity to == and !=) act on objects; when you write "MyObj a; ++a", you are calling an overloaded operator, not incrementing a pointer. "MyObj a, b; if (a > b)" calls a.cmp(b) and you don't even expect it to compare operators. So why should == and != act differently?

> do you realy use == that much ?

Maybe not. Maybe it's one more reason why I want it to behave coherently with other operators, so I don't have to remember too many rules and exceptions...

Also, while it is true that D references are not C++ references, D is not C++ after all. And anyway they are references, not pointers. So applying == to them should compare objects, IMO.

Ric

"Riccardo De Agostini" <riccardo.de.agostini@email.it> ha scritto nel messaggio news:bjsb2s$1t3$1@digitaldaemon.com...
> "MyObj a, b; if (a > b)" calls a.cmp(b) and you
> don't even expect it to compare operators.

Should have been "pointers" instead of "operators". No more Chinese food for lunch, I promise. :)

Walter (I know you'll be reading this...): don't you think that "is" (as in "if (a is b)") would be better than "===" for pointer equality check? The !== operator might even be eliminated, or maybe substituted by "is_not", "isnot" or something of the kind. This would make things clearer for both C++ experienced programmers (since they wouldn't have to remember which is which between == and ===) and people learning D from scratch or maybe with a Basic/Pascal/whatever background.

Ric

Riccardo De Agostini wrote:
> "Mike Wynn" <mike@l8night.co.uk> ha scritto nel messaggio
> news:bjs6pm$2tok$1@digitaldaemon.com...
> 
>>Riccardo De Agostini wrote:
>>
>>>"Mike Wynn" <mike@l8night.co.uk> ha scritto nel messaggio
>>>news:bjrf0m$1rpd$1@digitaldaemon.com...
>>
>>WHY!! that's what is causings the problems == being .cmp not &a == &b
> 
> 
> I'm sorry but I think the problem is not with the meaning of == and !=. I
> feel they act as they should, i.e. on objects as opposed to pointers. All
> other operators (with the exception of === and !===, about whom I share your
> feelings about the excessive visual similarity to == and !=) act on objects;
> when you write "MyObj a; ++a", you are calling an overloaded operator, not
> incrementing a pointer. "MyObj a, b; if (a > b)" calls a.cmp(b) and you
> don't even expect it to compare operators. So why should == and != act
> differently?
> 

I do accept that a > b would imply the values of a,b
and now my chocolate, caffine and nicotine levels are normalised

if (a is b) instead of === if looking very good

if ( a is null ) { .. }
but what for the oposite ?
if ( a is !null ) { .. }
if ( !(a is null) ) { .. }
I think the former is rather too influenced by perl ...
unless ( a is null ) { ... }




> 
>>do you realy use == that much ?
> 
> 
> Maybe not. Maybe it's one more reason why I want it to behave coherently
> with other operators, so I don't have to remember too many rules and
> exceptions...

I'm starting to see that it's ===/== that is winding me up not that == => .cmp and think I agree about the consistancy of == with <

currently I find that a === null (&a == null) or != null are my most common comparison on objects
&a < &b is very rare

> 
> Also, while it is true that D references are not C++ references, D is not
> C++ after all. And anyway they are references, not pointers. So applying ==
> to them should compare objects, IMO.

but `=` (which I still think should be `:=`) assignes the reference not the value

my vote has always been
a := foo;  (a gets shallow copy of foo/ value of a becomes the same as the value of foo)

f $= foo; (a now refers to the same things are foo refers to)

int func( Obj o ) {
	o := 9; // not allowed o is not an int or calls operator assign( int );
	o $= new Obj( 9 ); // o.k. (same as current `=`)
}

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

> I'm sorry but I think the problem is not with the meaning of == and !=. I feel they act as they should, i.e. on objects as opposed to pointers. All other operators (with the exception of === and !===, about whom I share your feelings about the excessive visual similarity to == and !=) act on objects;

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.

I think the meaning of == vs === should be swapped, it's just too subtle for all those C++ and Java programmers out there.

Afterall, the reasons for the current semantics seems not too compelling, to me.

Antti Sykari, had brought up some arguments why operator== should mean identity instead of equality: http://www.digitalmars.com/drn-bin/wwwnews?D/12295


Farmer.