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?


=== is identity, while == is equivalence
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?


 === 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
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?


 === 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.
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?


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



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



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


 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.
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) {}



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:






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


by

 myself and several others.

 I'd like to comment on


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



 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:






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




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.



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


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,

 by

 myself and several others.

 I'd like to comment on


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







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:






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




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,

 by

 myself and several others.

 I'd like to comment on


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







 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:












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




 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,

 by

 myself and several others.

 I'd like to comment on


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











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:












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




 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,

 by

 myself and several others.

 I'd like to comment on


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











 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:












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


it

 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




drop

 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




the

 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 reply Antti Sykari <jsykari gamma.hut.fi> writes:
Ilya Minkov <midiclub tiscali.de> writes:


 Farmer wrote:


 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) {}


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




for

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




If

so, which one is which?


 === is identity, while == is equivalence
Mar 25 2003