www.digitalmars.com         C & C++   DMDScript  

D - Identity & equivalence

reply "Matthew Wilson" <dmd synesis.com.au> writes:
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?
Mar 25 2003
parent reply Jon Allen <jallen minotstateu.edu> writes:
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?

Mar 25 2003
next sibling parent reply xyzzy <xyzzy adventure.com> writes:
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?


Why? I can see LOTS of people forgetting which is which unless there is a good rationale for the current position. -- xyzzy
Mar 25 2003
parent reply Jon Allen <jallen minotstateu.edu> writes:
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?


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.
Mar 25 2003
parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
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?


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.

Mar 25 2003
parent reply Farmer <itsFarmer. freenet.de> writes:
"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?


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.


Mar 26 2003
next sibling parent "Matthew Wilson" <dmd synesis.com.au> writes:
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?


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.



Mar 26 2003
prev sibling parent reply Ilya Minkov <midiclub tiscali.de> writes:
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
 }
 

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.
Mar 28 2003
next sibling parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
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


 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
 }

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.

Mar 29 2003
next sibling parent "Luna Kid" <lunakid neuropolis.org> writes:
(I'm starting another thread on this. Sab)
Mar 29 2003
prev sibling next sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
Jump off a cliff.  I like terse syntax.

if(i) {}
if(!x) {}

Both ok in my book.  Everybody knows what they mean (except you, perhaps).

Why should the only thing that produces a bool be a comparison?

Why should there not be operators especially for comparison against null and
zero?  Those *are* the most common cases.

Sean

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b64c71$2rgd$1 digitaldaemon.com...
 I think most of your points have been ably addressed in the other thread,

 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

 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

 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


 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
 }

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.


Mar 29 2003
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Sean L. Palmer wrote:
 Jump off a cliff.  I like terse syntax.
 
 if(i) {}
 if(!x) {}
 
 Both ok in my book.  Everybody knows what they mean (except you, perhaps).
 
 Why should the only thing that produces a bool be a comparison?
 
 Why should there not be operators especially for comparison against null and
 zero?  Those *are* the most common cases.
 
 Sean

Object o = ...; bit b = o; // O_O if (o == b) ...; // _ In any other context, it makes absolutely no sense. if (o !== null) doesn't strike me as being hyperverbose or tedious. -- andy
Mar 29 2003
parent "Luna Kid" <lunakid neuropolis.org> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:b64v57$6sd$1 digitaldaemon.com...
 Sean L. Palmer wrote:
 Jump off a cliff.  I like terse syntax.

 if(i) {}
 if(!x) {}

 Both ok in my book.  Everybody knows what they mean (except you,


 Why should the only thing that produces a bool be a comparison?

 Why should there not be operators especially for comparison against null


 zero?  Those *are* the most common cases.

 Sean

Object o = ...; bit b = o; // O_O if (o == b) ...; // _ In any other context, it makes absolutely no sense. if (o !== null) doesn't strike me as being hyperverbose or tedious.

Let's bring this if(x) topic to the new thread I started for it: 'On "if (x)" and initialization...'. The reason people have endless debates on this issue is because no language properly support the abstraction expressed by if(x), so some see it as "real if with bool", and others see it "checking for usable object". Both are perfectly valid and common uses, but they are different things, expressed with the same syntax. That reads: poor language design. As Sean said: "Why should there not be operators especially for comparison against null and zero? Those *are* the most common cases." Absolutely on the point. That if (x) is a hack that most practical languages *encourage* to use, because they knowingly acknowledge its parctical value, but still not developed enough to have explicit syntactic (and semantic) facilities for supporting the deeper meaning of that statement. Luna Kid
Mar 29 2003
prev sibling parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
How impolite

"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b64t3q$5l4$1 digitaldaemon.com...
 Jump off a cliff.  I like terse syntax.

 if(i) {}
 if(!x) {}

 Both ok in my book.  Everybody knows what they mean (except you, perhaps).

 Why should the only thing that produces a bool be a comparison?

 Why should there not be operators especially for comparison against null

 zero?  Those *are* the most common cases.

 Sean

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:b64c71$2rgd$1 digitaldaemon.com...
 I think most of your points have been ably addressed in the other


 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


 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


 proposition that the extra typing to get to

 if(i != 0)
 {

 if(x == null)
 {

 isn't infinitesimally insignificant when compared to the codification of

 rest of the source, not to mention the costs in terms of extra


 by doing such things.

 If there's one criticism I'd make of the thrust of lots of arguments in

 newsgroup, it is the focus on the convenience of code authors without


 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


 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
 }

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



 - 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



 dereferencing is not yet program's death. And you don't have to



 it in every line of a program. Your functions don't even have to yuild



 dead object in first place - why don't you just raise your own



 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?



 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



 look at lots of code, it often uses pointer equality for comparisons,
 and thus under no circumstances copies objects unless they change.



 may be somewhat error-prone and restricts the use of functional



 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.



Mar 29 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
He called my proposition ludicrous!  ;)

Sean

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b65aqc$f0n$1 digitaldaemon.com...
 How impolite

 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b64t3q$5l4$1 digitaldaemon.com...
 Jump off a cliff.  I like terse syntax.

 if(i) {}
 if(!x) {}

 Both ok in my book.  Everybody knows what they mean (except you,


 Why should the only thing that produces a bool be a comparison?

 Why should there not be operators especially for comparison against null

 zero?  Those *are* the most common cases.

 Sean

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:b64c71$2rgd$1 digitaldaemon.com...
 I think most of your points have been ably addressed in the other


 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


 better than C and C++ (and, I think, D). The expressions in



 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


 proposition that the extra typing to get to

 if(i != 0)
 {

 if(x == null)
 {

 isn't infinitesimally insignificant when compared to the codification



 the
 rest of the source, not to mention the costs in terms of extra


 by doing such things.

 If there's one criticism I'd make of the thrust of lots of arguments



 this
 newsgroup, it is the focus on the convenience of code authors without


 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





 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
 }

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




 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




 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



 - 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



 dereferencing is not yet program's death. And you don't have to



 it in every line of a program. Your functions don't even have to




 a
 dead object in first place - why don't you just raise your own



 and catch it on the upper level without cluttering your code with
 pointer checks? Dead object usually *is* an error indicator. An




 which has been destroyed and then reused or simply stored away?



 RAII. And aren't exceptions better because they almost don't slow




 the normal case code?

 I think the c++ decision came from underlying implementation. And if



 look at lots of code, it often uses pointer equality for




 and thus under no circumstances copies objects unless they change.



 may be somewhat error-prone and restricts the use of functional



 in everyday programming.

 As to efficiency, you would first want a running program, and then




 could see where efficiency suffers and fix it. At this later stage,




 imposes no restriction on it. You can guess nowever you like, but




 never knows what makes the program slow before some actual




 -i.




Mar 30 2003
parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
Quit & peace, my brother. :)

"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b67g10$1raq$1 digitaldaemon.com...
 He called my proposition ludicrous!  ;)

 Sean

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:b65aqc$f0n$1 digitaldaemon.com...
 How impolite

 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b64t3q$5l4$1 digitaldaemon.com...
 Jump off a cliff.  I like terse syntax.

 if(i) {}
 if(!x) {}

 Both ok in my book.  Everybody knows what they mean (except you,


 Why should the only thing that produces a bool be a comparison?

 Why should there not be operators especially for comparison against



 and
 zero?  Those *are* the most common cases.

 Sean

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:b64c71$2rgd$1 digitaldaemon.com...
 I think most of your points have been ably addressed in the other


 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




 far
 better than C and C++ (and, I think, D). The expressions in



 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


 proposition that the extra typing to get to

 if(i != 0)
 {

 if(x == null)
 {

 isn't infinitesimally insignificant when compared to the




 of
 the
 rest of the source, not to mention the costs in terms of extra


 by doing such things.

 If there's one criticism I'd make of the thrust of lots of arguments



 this
 newsgroup, it is the focus on the convenience of code authors




 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





 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
 }

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





 (Warning!), but it may be requiered to be able to compare 2





 by
 reference.

 However, it is much more intuitive to compare by contents. You





 a==b to compare integers by contents, not by reference. So why




 you make it all inconsistent and compare other things by





 Forget of objects being pointers. They are objects. Simply that.





 understand that carrying around dead objects (yes, that's what





 are
 - the NULL ponters) is harmful anyway and requieres questioning





 concept. Read the Daniel's comment on the "null == o?" thread.

 BTW, with good exception handling, like the one D promises, NULL



 dereferencing is not yet program's death. And you don't have to



 it in every line of a program. Your functions don't even have to




 a
 dead object in first place - why don't you just raise your own



 and catch it on the upper level without cluttering your code with
 pointer checks? Dead object usually *is* an error indicator. An




 which has been destroyed and then reused or simply stored away?



 RAII. And aren't exceptions better because they almost don't slow




 the normal case code?

 I think the c++ decision came from underlying implementation. And





 you
 look at lots of code, it often uses pointer equality for




 and thus under no circumstances copies objects unless they change.



 may be somewhat error-prone and restricts the use of functional



 in everyday programming.

 As to efficiency, you would first want a running program, and then




 could see where efficiency suffers and fix it. At this later





 D
 imposes no restriction on it. You can guess nowever you like, but




 never knows what makes the program slow before some actual




 -i.





Mar 30 2003
next sibling parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
Sorry, that should have read "Quits", as in we're quits, as in let's drop it
with pride preserved on both sides. I didn't mean "Quit", as in shut up
naughty boy.

:)

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b67nih$211k$1 digitaldaemon.com...
 Quit & peace, my brother. :)

 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b67g10$1raq$1 digitaldaemon.com...
 He called my proposition ludicrous!  ;)

 Sean

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:b65aqc$f0n$1 digitaldaemon.com...
 How impolite

 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b64t3q$5l4$1 digitaldaemon.com...
 Jump off a cliff.  I like terse syntax.

 if(i) {}
 if(!x) {}

 Both ok in my book.  Everybody knows what they mean (except you,


 Why should the only thing that produces a bool be a comparison?

 Why should there not be operators especially for comparison against



 and
 zero?  Those *are* the most common cases.

 Sean

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:b64c71$2rgd$1 digitaldaemon.com...
 I think most of your points have been ably addressed in the other


 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




 far
 better than C and C++ (and, I think, D). The expressions in



 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


 proposition that the extra typing to get to

 if(i != 0)
 {

 if(x == null)
 {

 isn't infinitesimally insignificant when compared to the




 of
 the
 rest of the source, not to mention the costs in terms of extra


 by doing such things.

 If there's one criticism I'd make of the thrust of lots of





 in
 this
 newsgroup, it is the focus on the convenience of code authors




 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





 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
 }

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





 (Warning!), but it may be requiered to be able to compare 2





 by
 reference.

 However, it is much more intuitive to compare by contents. You





 a==b to compare integers by contents, not by reference. So why




 you make it all inconsistent and compare other things by





 Forget of objects being pointers. They are objects. Simply that.





 understand that carrying around dead objects (yes, that's what





 are
 - the NULL ponters) is harmful anyway and requieres questioning





 concept. Read the Daniel's comment on the "null == o?" thread.

 BTW, with good exception handling, like the one D promises, NULL



 dereferencing is not yet program's death. And you don't have to



 it in every line of a program. Your functions don't even have to




 a
 dead object in first place - why don't you just raise your own



 and catch it on the upper level without cluttering your code






 pointer checks? Dead object usually *is* an error indicator. An




 which has been destroyed and then reused or simply stored away?



 RAII. And aren't exceptions better because they almost don't






 down
 the normal case code?

 I think the c++ decision came from underlying implementation.






 if
 you
 look at lots of code, it often uses pointer equality for




 and thus under no circumstances copies objects unless they






 This
 may be somewhat error-prone and restricts the use of functional



 in everyday programming.

 As to efficiency, you would first want a running program, and






 you
 could see where efficiency suffers and fix it. At this later





 D
 imposes no restriction on it. You can guess nowever you like,






 one
 never knows what makes the program slow before some actual




 -i.






Mar 30 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
I grok.

I do think we should continue to debate this important issue, but without
the evilness.  ;)

Unless the higher-ups deem it a hopeless religious war!

Sean

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b67ot3$21qk$1 digitaldaemon.com...
 Sorry, that should have read "Quits", as in we're quits, as in let's drop

 with pride preserved on both sides. I didn't mean "Quit", as in shut up
 naughty boy.

 :)

Mar 30 2003
parent "Matthew Wilson" <dmd synesis.com.au> writes:
My plan is to work on all the intransigent opposing advocates, and once a
concerted POV is achieved to hit Walter with the newsgroup stick. (I must
say, I'm not terribly confident of achieving even the first part of that,
much less so the latter)

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:b67t5r$24q0$1 digitaldaemon.com...
 I grok.

 I do think we should continue to debate this important issue, but without
 the evilness.  ;)

 Unless the higher-ups deem it a hopeless religious war!

 Sean

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:b67ot3$21qk$1 digitaldaemon.com...
 Sorry, that should have read "Quits", as in we're quits, as in let's


 it
 with pride preserved on both sides. I didn't mean "Quit", as in shut up
 naughty boy.

 :)


Mar 30 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
It's all in good fun.

Mainly I reply here because I noticed I still had my old email address set
for this server.  In case anyone tried to email me directly please note the
new addy.

Sean

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b67nih$211k$1 digitaldaemon.com...
 Quit & peace, my brother. :)

 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b67g10$1raq$1 digitaldaemon.com...
 He called my proposition ludicrous!  ;)

 Sean


Mar 30 2003
prev sibling parent reply Farmer <itsFarmer. freenet.de> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in
news:b64c71$2rgd$1 digitaldaemon.com: 

[snip]
 
 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) 
 
 

Here is some more stuff for upcoming D maintainerns to struggle with :-( int*[10] fooArray; fooArray[]=foo2; If you don't know foo2's type then you cannot guess what's happening: a) assuming int* foo2; fooArray is set to values of int* (like C memset). b) assuming int[9] foo2; The content of foo2 is copied to fooArray (like C memcopy). [Actually you get a runtime error "lengths don't match for array copy", for this example] By convention you could waste (read invest) 2 characters for writting fooArray[]=foo2[]; // xxx[]=xxx[] means "memcopy" whenever foo2 is an array in order to make things more obvious. int*[10] fooArray; foo3=fooArray; Again you don't know foo3's type. Then two very similar things could happen: a)assuming void* foo3; The address of fooArray's content is taken. [In case a) the writer might intended "foo3=fooArray[1];" instead of "foo3=fooArray;"] b)assuming int*[10] foo3; Foo3 is aliased to fooArray. By convention you could write foo3=&fooArray[0]; or foo3=cast(void*)fooArray[0]; whenever you convert an array to a mere pointer, in order to alert maintainers that some unsafe array operations with foo3 lie ahead. [But don't write "foo3=&fooArray;" it's a bug!] Now, let's combine D's implicit array to pointer conversion with the "memset" behaviour of the assigment operator: int [10] array; // Or was int*[10] array intended ? int*[10] fooArray; // looks like a memcopy, but actually a memset is performed ! fooArray[]=array[]; Maybe a I'd better forget about my D conventions, and go back to assembler commenting style for D. Farmer.
Mar 30 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
I've saved this one as unread, and come back to it this morning. Nasty
stuff. (I'm setting to unread again, as this'll need more thinking in the
future.)

Walter, I'd be interested in your comments on all the examples.



"Farmer" <itsFarmer. freenet.de> wrote in message
news:Xns934ED20ADBED6itsFarmer 63.105.9.61...
 "Matthew Wilson" <dmd synesis.com.au> wrote in
 news:b64c71$2rgd$1 digitaldaemon.com:

 [snip]
 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)

Here is some more stuff for upcoming D maintainerns to struggle with :-( int*[10] fooArray; fooArray[]=foo2; If you don't know foo2's type then you cannot guess what's happening: a) assuming int* foo2; fooArray is set to values of int* (like C memset). b) assuming int[9] foo2; The content of foo2 is copied to fooArray (like C memcopy). [Actually you get a runtime error "lengths don't match for array copy", for this example] By convention you could waste (read invest) 2 characters for writting fooArray[]=foo2[]; // xxx[]=xxx[] means "memcopy" whenever foo2 is an array in order to make things more obvious. int*[10] fooArray; foo3=fooArray; Again you don't know foo3's type. Then two very similar things could happen: a)assuming void* foo3; The address of fooArray's content is taken. [In case a) the writer might intended "foo3=fooArray[1];" instead of "foo3=fooArray;"] b)assuming int*[10] foo3; Foo3 is aliased to fooArray. By convention you could write foo3=&fooArray[0]; or foo3=cast(void*)fooArray[0]; whenever you convert an array to a mere pointer, in order to alert maintainers that some unsafe array operations with foo3 lie ahead. [But don't write "foo3=&fooArray;" it's a bug!] Now, let's combine D's implicit array to pointer conversion with the "memset" behaviour of the assigment operator: int [10] array; // Or was int*[10] array intended ? int*[10] fooArray; // looks like a memcopy, but actually a memset is performed ! fooArray[]=array[]; Maybe a I'd better forget about my D conventions, and go back to assembler commenting style for D. Farmer.

May 21 2003
parent reply "Walter" <walter digitalmars.com> writes:
There are some good ideas there.

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bah9kg$kdi$1 digitaldaemon.com...
 I've saved this one as unread, and come back to it this morning. Nasty
 stuff. (I'm setting to unread again, as this'll need more thinking in the
 future.)

 Walter, I'd be interested in your comments on all the examples.

May 24 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Any responses on this one yet?

"Walter" <walter digitalmars.com> wrote in message
news:bapdri$gir$1 digitaldaemon.com...
 There are some good ideas there.

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bah9kg$kdi$1 digitaldaemon.com...
 I've saved this one as unread, and come back to it this morning. Nasty
 stuff. (I'm setting to unread again, as this'll need more thinking in


 future.)

 Walter, I'd be interested in your comments on all the examples.


Jul 09 2003
parent "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:beid7n$jh2$2 digitaldaemon.com...
 Any responses on this one yet?

Not yet!
Jul 10 2003
prev sibling next sibling parent "Luna Kid" <lunakid neuropolis.org> writes:
 The language _could_ have, for incurable C hackers and other friends
 of terse syntax, conversions such as -- hypothetical syntax:

...

 void convert(Object object, out bit isNonNull)

 ...

 and so on.  And "if (object)" would automatically convert the object
 to bool.

 And by the way, I'd just *love* to have other user-defined conversions
 between different types as well.

 (Maybe this is asking too much - perhaps it's better to stop before
 the language starts to approach C++ in complexity, right?)

 -Antti

Some of it *is* practical. All of it, unleashed, leads to horror you can see in C++. I cannot tell where the balance is, but I can tell you that many people use it and love it -- it's not just you alone. It is a valid need. Millions write that. And they are not all just stupid. (Implicit conversions between different number types are already done, and you'd laugh at a C-like language missing them. Most of the time, implicit conversion to boolean, if you look at it, is really just a tool to support checking for "object reliability". "Trueness", if you wish, not in the real bool sense, but regarding "trust".) People use "if (x)", because there is no better alternative. There *are* doznes of good alternatives, but things like if (x.initialized) may not be *better* alternatives in every cases, and they are -- despite being very common real-world problems -- definitely not standard and have no built-in support in practically any language. (Partly because it's not trivial to support.) (I'm a strong "believer" in the laws of phisics, like the minimum energy principle, and I also like doing things the most convenient and simple ways. As one Finnish civil engineer (I guess you know this better, Antti :) ) once designed a park: he let people walking across it for a while, and where they walked out the grass, there he finally put the paved passages...) Cheers, Luna Kid
Mar 29 2003
prev sibling parent Farmer <itsFarmer. freenet.de> writes:
Ilya Minkov <midiclub tiscali.de> wrote in
news:b61ii2$mft$1 digitaldaemon.com: 

 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. [...]

I don't buy that. I prefer to stick to the truth.
 BTW, with good exception handling, like the one D promises, NULL
 pointer dereferencing is not yet program's death. [...]

To my best knowledge, D promises nothing when dereferencing "null objects". (a)my D compiler (DMD 0.58) does not do any checks (b)the D spec contains nothing about it (c)there is nothing like a nullPointerError in Phobos code
 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?

You are absolutely right on this. But it is difficult to stop people from doing such nonsense: I actually took the offending code, from a Java programm. It has been written by a professional programmer who has experience in Visual Basic, C, C++ and Java. Farmer.
Mar 30 2003
prev sibling next sibling parent "Matthew Wilson" <dmd synesis.com.au> writes:
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


representing equivalence and identity. Is this correct? Still the case?


so, which one is which?


Mar 25 2003
prev sibling parent Antti Sykari <jsykari gamma.hut.fi> writes:
Ilya Minkov <midiclub tiscali.de> writes:

 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
 }

if (obj) {} if (!obj) {}

Certainly the if () construct must only have boolean bit values. All right. The language _could_ have, for incurable C hackers and other friends of terse syntax, conversions such as -- hypothetical syntax: module global_conversions; void convert(Object object, out bit isNonNull) { isNonNull = object !== null; } void convert(int number, out bit isNonZero) { isNonZero = object !== 0; } and so on. And "if (object)" would automatically convert the object to bool. And by the way, I'd just *love* to have other user-defined conversions between different types as well. (Maybe this is asking too much - perhaps it's better to stop before the language starts to approach C++ in complexity, right?) -Antti
Mar 29 2003