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

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

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

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

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

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

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.

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

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:beid7n$jh2$2@digitaldaemon.com...
> Any responses on this one yet?

Not yet!