(I'm starting another thread on this. Sab)

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

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

"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

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

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

> 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

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.

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

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