If I remember, last year there was debate on using == and === operators for representing equivalence and identity. Is this correct? Still the case? If so, which one is which?

In article <b5r826$2pjt$1@digitaldaemon.com>, Matthew Wilson says...
>
>If I remember, last year there was debate on using == and === operators for representing equivalence and identity. Is this correct? Still the case? If so, which one is which?
>
>
>
>
=== is identity, while == is equivalence

On Wed, 26 Mar 2003 04:05:35 +0000 (UTC), Jon Allen <jallen@minotstateu.edu> wrote:

> In article <b5r826$2pjt$1@digitaldaemon.com>, Matthew Wilson says...
>>
>> If I remember, last year there was debate on using == and === operators for
>> representing equivalence and identity. Is this correct? Still the case? If
>> so, which one is which?
>>
>>
>>
>>
> === is identity, while == is equivalence

Why? I can see LOTS of people forgetting which is which unless there is a good rationale for the current position.

-- 
xyzzy

Cheers, mate. :)

"Jon Allen" <jallen@minotstateu.edu> wrote in message news:b5r8uf$2qhb$1@digitaldaemon.com...
> In article <b5r826$2pjt$1@digitaldaemon.com>, Matthew Wilson says...
> >
> >If I remember, last year there was debate on using == and === operators
for
> >representing equivalence and identity. Is this correct? Still the case?
If
> >so, which one is which?
> >
> >
> >
> >
> === is identity, while == is equivalence
>
>

xyzzy wrote:
> On Wed, 26 Mar 2003 04:05:35 +0000 (UTC), Jon Allen <jallen@minotstateu.edu> wrote:
> 
>> In article <b5r826$2pjt$1@digitaldaemon.com>, Matthew Wilson says...
>>
>>>
>>> If I remember, last year there was debate on using == and === operators for
>>> representing equivalence and identity. Is this correct? Still the case? If
>>> so, which one is which?
>>>
>>>
>>>
>>>
>> === is identity, while == is equivalence
> 
> 
> Why? I can see LOTS of people forgetting which is which unless there is a good rationale for the current position.
> 

== is already equivalence in C and D is based on C.  It kind of follows that === is more equal, or the identity.  At least that's how I think of it.  I don't know if it's a _good_ reason, but it works for me.

The reasoning is sound. I'm glad it's not changed from the position last year, as I think it's at the zenith of sense.

"Jon Allen" <jallen@minotstateu.edu> wrote in message news:b5ranu$2rnb$1@digitaldaemon.com...
> xyzzy wrote:
> > On Wed, 26 Mar 2003 04:05:35 +0000 (UTC), Jon Allen
> > <jallen@minotstateu.edu> wrote:
> >
> >> In article <b5r826$2pjt$1@digitaldaemon.com>, Matthew Wilson says...
> >>
> >>>
> >>> If I remember, last year there was debate on using == and ===
> >>> operators for
> >>> representing equivalence and identity. Is this correct? Still the
> >>> case? If
> >>> so, which one is which?
> >>>
> >>>
> >>>
> >>>
> >> === is identity, while == is equivalence
> >
> >
> > Why? I can see LOTS of people forgetting which is which unless there is a good rationale for the current position.
> >
>
> == is already equivalence in C and D is based on C.  It kind of follows that === is more equal, or the identity.  At least that's how I think of it.  I don't know if it's a _good_ reason, but it works for me.
>

"Matthew Wilson" <dmd@synesis.com.au> wrote in news:b5rf0o$2unl$1@digitaldaemon.com:

> The reasoning is sound. I'm glad it's not changed from the position last year, as I think it's at the zenith of sense.

Just a few thousands C, C++, Java and C# programmers will experience quite a suprise when their newly written D code crashes !

SomeClass obj;
if (obj != null)  // access violation when obj===null
{
   // do sth. with obj
}
if (obj == null) // access violation when obj===null
{
   obj=new SomeClass(); // init now
}


The D compiler issues no warning for possible use of uninitialized reference to 'obj'. Furthermore there aren't any automatic nullpointer checks in D. Too bad, that the (incorrect) explicit nullpointer checks won't help, either. When programming in D, better get your debugger started ;-)




Farmer.



> 
> "Jon Allen" <jallen@minotstateu.edu> wrote in message news:b5ranu$2rnb$1@digitaldaemon.com...
>> xyzzy wrote:
>> > On Wed, 26 Mar 2003 04:05:35 +0000 (UTC), Jon Allen
>> > <jallen@minotstateu.edu> wrote:
>> >
>> >> In article <b5r826$2pjt$1@digitaldaemon.com>, Matthew Wilson says...
>> >>
>> >>>
>> >>> If I remember, last year there was debate on using == and ===
>> >>> operators for
>> >>> representing equivalence and identity. Is this correct? Still the
>> >>> case? If
>> >>> so, which one is which?
>> >>>
>> >>>
>> >>>
>> >>>
>> >> === is identity, while == is equivalence
>> >
>> >
>> > Why? I can see LOTS of people forgetting which is which unless there is a good rationale for the current position.
>> >
>>
>> == is already equivalence in C and D is based on C.  It kind of follows that === is more equal, or the identity.  At least that's how I think of it.  I don't know if it's a _good_ reason, but it works for me.
>>
> 
> 

No, say it ain't so!

I guess this touches on my other thread "null == o?", on which I've only just read the single response.

This all sucks enormously! I kind of understand the efficiency reason for == not checking for null before conducting its comparisons, but it's nowhere near a sufficient reason.

[I'm taking this onto the other thread.]

"Farmer" <itsFarmer.@freenet.de> wrote in message news:Xns934B783EDAFEitsFarmer@63.105.9.61...
> "Matthew Wilson" <dmd@synesis.com.au> wrote in news:b5rf0o$2unl$1@digitaldaemon.com:
>
> > The reasoning is sound. I'm glad it's not changed from the position last year, as I think it's at the zenith of sense.
>
> Just a few thousands C, C++, Java and C# programmers will experience quite a suprise when their newly written D code crashes !
>
> SomeClass obj;
> if (obj != null)  // access violation when obj===null
> {
>    // do sth. with obj
> }
> if (obj == null) // access violation when obj===null
> {
>    obj=new SomeClass(); // init now
> }
>
>
> The D compiler issues no warning for possible use of uninitialized
> reference to 'obj'. Furthermore there aren't any automatic nullpointer
> checks in D. Too bad, that the (incorrect) explicit nullpointer checks
> won't help, either.
> When programming in D, better get your debugger started ;-)
>
>
>
>
> Farmer.
>
>
>
> >
> > "Jon Allen" <jallen@minotstateu.edu> wrote in message news:b5ranu$2rnb$1@digitaldaemon.com...
> >> xyzzy wrote:
> >> > On Wed, 26 Mar 2003 04:05:35 +0000 (UTC), Jon Allen
> >> > <jallen@minotstateu.edu> wrote:
> >> >
> >> >> In article <b5r826$2pjt$1@digitaldaemon.com>, Matthew Wilson says...
> >> >>
> >> >>>
> >> >>> If I remember, last year there was debate on using == and ===
> >> >>> operators for
> >> >>> representing equivalence and identity. Is this correct? Still the
> >> >>> case? If
> >> >>> so, which one is which?
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >> === is identity, while == is equivalence
> >> >
> >> >
> >> > Why? I can see LOTS of people forgetting which is which unless there is a good rationale for the current position.
> >> >
> >>
> >> == is already equivalence in C and D is based on C.  It kind of follows that === is more equal, or the identity.  At least that's how I think of it.  I don't know if it's a _good_ reason, but it works for me.
> >>
> >
> >
>

Farmer wrote:
> Just a few thousands C, C++, Java and C# programmers will experience quite a suprise when their newly written D code crashes !
> 
> SomeClass obj;
> if (obj != null)  // access violation when obj===null
> {
>    // do sth. with obj
> }
> if (obj == null) // access violation when obj===null
> {
>    obj=new SomeClass(); // init now
> }
> 
Wouldn't you normally write ?:
if (obj) {}
if (!obj) {}

This looks much more meaningful anyway. You test an object for existance, that is "to be or not to be". :)

Basically, you don't need to be able to compare an object with NULL (Warning!), but it may be requiered to be able to compare 2 objects by reference.

However, it is much more intuitive to compare by contents. You write a==b to compare integers by contents, not by reference. So why should you make it all inconsistent and compare other things by reference? Forget of objects being pointers. They are objects. Simply that. And understand that carrying around dead objects (yes, that's what they are - the NULL ponters) is harmful anyway and requieres questioning your concept. Read the Daniel's comment on the "null == o?" thread.

BTW, with good exception handling, like the one D promises, NULL pointer dereferencing is not yet program's death. And you don't have to consider it in every line of a program. Your functions don't even have to yuild a dead object in first place - why don't you just raise your own exception and catch it on the upper level without cluttering your code with pointer checks? Dead object usually *is* an error indicator. An object which has been destroyed and then reused or simply stored away? Remember RAII. And aren't exceptions better because they almost don't slow down the normal case code?

I think the c++ decision came from underlying implementation. And if you look at lots of code, it often uses pointer equality for comparisons, and thus under no circumstances copies objects unless they change. This may be somewhat error-prone and restricts the use of functional concepts in everyday programming.

As to efficiency, you would first want a running program, and then you could see where efficiency suffers and fix it. At this later stage, D imposes no restriction on it. You can guess nowever you like, but one never knows what makes the program slow before some actual profiling.

-i.

I think most of your points have been ably addressed in the other thread, by myself and several others.

I'd like to comment on

> Wouldn't you normally write ?:
> if (obj) {}
> if (!obj) {}

No. Absolutely not. Here is something that C# and D have done that is far better than C and C++ (and, I think, D). The expressions in conditionals should be explicitly boolean. Hence

int    i = 1;
X    x = new X();

if(i)
{

if(!x)
{

Neither of those are sensible syntax. They are pandering to the ludicrous proposition that the extra typing to get to

if(i != 0)
{

if(x == null)
{

isn't infinitesimally insignificant when compared to the codification of the rest of the source, not to mention the costs in terms of extra maintenance by doing such things.

If there's one criticism I'd make of the thrust of lots of arguments in this newsgroup, it is the focus on the convenience of code authors without much thought for code maintainers (even where coder === the maintainer)







"Ilya Minkov" <midiclub@tiscali.de> wrote in message news:b61ii2$mft$1@digitaldaemon.com...
> Farmer wrote:
> > Just a few thousands C, C++, Java and C# programmers will experience
quite
> > a suprise when their newly written D code crashes !
> >
> > SomeClass obj;
> > if (obj != null)  // access violation when obj===null
> > {
> >    // do sth. with obj
> > }
> > if (obj == null) // access violation when obj===null
> > {
> >    obj=new SomeClass(); // init now
> > }
> >
> Wouldn't you normally write ?:
> if (obj) {}
> if (!obj) {}
>
> This looks much more meaningful anyway. You test an object for existance, that is "to be or not to be". :)
>
> Basically, you don't need to be able to compare an object with NULL (Warning!), but it may be requiered to be able to compare 2 objects by reference.
>
> However, it is much more intuitive to compare by contents. You write a==b to compare integers by contents, not by reference. So why should you make it all inconsistent and compare other things by reference? Forget of objects being pointers. They are objects. Simply that. And understand that carrying around dead objects (yes, that's what they are - the NULL ponters) is harmful anyway and requieres questioning your concept. Read the Daniel's comment on the "null == o?" thread.
>
> BTW, with good exception handling, like the one D promises, NULL pointer dereferencing is not yet program's death. And you don't have to consider it in every line of a program. Your functions don't even have to yuild a dead object in first place - why don't you just raise your own exception and catch it on the upper level without cluttering your code with pointer checks? Dead object usually *is* an error indicator. An object which has been destroyed and then reused or simply stored away? Remember RAII. And aren't exceptions better because they almost don't slow down the normal case code?
>
> I think the c++ decision came from underlying implementation. And if you look at lots of code, it often uses pointer equality for comparisons, and thus under no circumstances copies objects unless they change. This may be somewhat error-prone and restricts the use of functional concepts in everyday programming.
>
> As to efficiency, you would first want a running program, and then you could see where efficiency suffers and fix it. At this later stage, D imposes no restriction on it. You can guess nowever you like, but one never knows what makes the program slow before some actual profiling.
>
> -i.
>