Mike Wynn wrote:
> Antti Sykäri wrote:
> 
>> In article <bjvljt$1m5i$1@digitaldaemon.com>, Sean L. Palmer wrote:
>>
>>> "Mike Wynn" <mike@l8night.co.uk> wrote in message
>>> news:bjtmft$1ub4$1@digitaldaemon.com...
>>>
>>>> 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 would like this better.  If you want to compare addresses, compare
>>> addresses... there is an address-of operator in D.
>>
>>
>>
>> Which brings us the problem that we should treat objects the same as structs.
>> But we cannot, because we don't know their actual size beforehand and therefore
>> cannot put them on the stack. So class objects remain, practically, pointers.
>>
>> And taking a pointer of the object would be like taking an address of a smart
>> pointer class in C++. Which one wouldn't under normal circumstances do.
>>
>> It's funny, I never really thought it was legal to take an address of an
>> object, but it works:
>>
>> void main()
>> {
>>     Object o1 = new Object;
>>     Object o2 = o1;
>>
>>     printf("o1 == %08x, o2 == %08x, &o1 == %08x, &o2 == %08x\n",
>>         o1, o2, &o1, &o2);
>> }
>>
>> o1 == 00870fd0, o2 == 00870fd0, &o1 == 0012ff30, &o2 == 0012ff34
>>
>> So &o1 !== &o2 but o1 != o2. In fact, &o1 == &o2 implies o1 === o2, which in
>> turn implies o1 == o2. (Well, except if o1 is null, in which case the
>> comparison crashes. So much for the fine theory) And &o1 == &o2 in fact is true
>> only if it's the same variable.
>>
>> -Antti
>>
> 
> your right ... currently &o is (void*)o
> 
> so what I wrote as ( &a == &b ) is infact
> ( cast(void*)a == cast(void*)b )
> 

what I mean is what I wrote as &a is the same as the current cast(void*)
&a currently means address of the variable as D objects are not references but pointers.
oj reflection
Obj a;
Obj * f = &a; //<=  means that (&a == &b) will only be true is a is b!

so I guess === and !== have to stay unless a new object operator is introduce to cast the object to a `void*`
@ or $ seem likely
( @a == @b ) => ( cast(void*)a === cast(void*)b )

On Fri, 12 Sep 2003 11:18:25 +0200 (09/12/03 19:18:25)
, Riccardo De Agostini <riccardo.de.agostini@email.it> 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?
>
> 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

Don't be silly, Riccardo. That would make code more readible and give us less opportunities to have debug session.

-- 
Derek

<G>

"Derek Parnell" <Derek.Parnell@No.Spam> wrote in message news:oprvilbpcryj5swd@news.digitalmars.com...
> On Fri, 12 Sep 2003 11:18:25 +0200 (09/12/03 19:18:25)
> , Riccardo De Agostini <riccardo.de.agostini@email.it> 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?
> >
> > 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
>
> Don't be silly, Riccardo. That would make code more readible and give us less opportunities to have debug session.
>
> -- 
> Derek

"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

"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.

IMHO == should mean equality when applied to references, just as + does not sum addresses as long as you don't apply it to pointers. It seems more logical to me.

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

"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bjth3u$1n2l$1@digitaldaemon.com...
> We need == (equality), is (identity) and isa (type membership).

I agree 100% on all three (although it was needless to say for the first
two...)

Ric

"Mike Wynn" <mike@l8night.co.uk> ha scritto nel messaggio news:bjtm1j$1tfk$2@digitaldaemon.com...
> so ( a == null ) would always be false ?

"(a == null)" does not even make sense, IMHO. It should be "(a === null)",
if checking for an unassigned reference was what you intended.

"(a is null)" would be better, but the current compiler (still) has "==="...

Ric

"Patrick Down" <Patrick_member@pathlink.com> ha scritto nel messaggio news:bjtltk$1thb$1@digitaldaemon.com...
> 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);

This seems very odd to me. A language that implements design by contract should not implicitly allow this kind of defensive programming.

In other words, if "a + null" bombs, "a == null" should bomb, too. "==", when applied to references, is just an overloaded operator. What if you have "a == b" and b is null because of a programming error? I expect the expression to explode into microscopic pieces when evaluated, not just to return false.

If you wanted that to be valid only when null is specified as a constant, what's wrong in "a is null"?

Ric

"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

is isa better than ===, and so is isa.

:)

"Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in message 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
>
>