Mmm... Actuall, I start liking Sean's "with" idea more and more:

    > Or perhaps this behavior could be made part of the 'with' statement:
    >
    > with(o)  // skips the whole block if o is null
    > {
    > }

Luna Kid


"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b67tuh$255m$1@digitaldaemon.com...
> Pedant!  ;)
>
> Sean
>
> "Luna Kid" <lunakid@neuropolis.org> wrote in message news:b67ppn$22jn$1@digitaldaemon.com...
> > I have to second, what Matt said.
> >
> > Sean,
> >
> > > > Perhaps what is needed is an explicit conversion to bool,
> >
> > It should read:
> >
> > > > Perhaps what is needed is an explicit conversion to bool.
> >
> > ;)
> >
> > Cheers,
> > Luna Kid
>
>

> Mmm... Actuall, I start liking Sean's "with" idea more and more:
>
>     > Or perhaps this behavior could be made part of the 'with' statement:
>     >
>     > with(o)  // skips the whole block if o is null
>     > {
>     > }

Just for the record: depending on the (awaited) resolution
of the recently discussed paradox of

    "references can be null and cannot be null"

with(o) becomes redundant if "references cannot be null"
will be chosen. (Which is very unlikely, I'd guess.)

Luna Kid

> >     > Or perhaps this behavior could be made part of the 'with'
statement:
> >     >
> >     > with(o)  // skips the whole block if o is null
> >     > {
> >     > }
>
> Just for the record: depending on the (awaited) resolution
> of the recently discussed paradox of
>
>     "references can be null and cannot be null"
>
> with(o) becomes redundant if "references cannot be null"

(Ehhhhh... I mean the null-checking. Anyway, why I wrote that message trivial at all?... Man, I need a sleep again... Sorry!)

Lunatic Kid

> (Ehhhhh... I mean the null-checking. Anyway, why I wrote that message trivial at all?... Man, I need a sleep again...
       ^^^^^^^^^^^^^^^

Nahhh, night good, folks...

>
> When you encounter the line
>
>   if (hilavitkutin != null)
>

you've not got what you expected ....
the above code will seggy if hilavitkutin is null

you mean
if (hilavitkutin !== null)  // ! = =

I agree it seems kinda nice, but how to do complex conditional, involving perhaps a couple of objects, and maybe other conditions?



"Luna Kid" <lunakid@neuropolis.org> wrote in message news:b6aerf$158r$1@digitaldaemon.com...
> Mmm... Actuall, I start liking Sean's "with" idea more and more:
>
>     > Or perhaps this behavior could be made part of the 'with' statement:
>     >
>     > with(o)  // skips the whole block if o is null
>     > {
>     > }
>
> Luna Kid
>
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b67tuh$255m$1@digitaldaemon.com...
> > Pedant!  ;)
> >
> > Sean
> >
> > "Luna Kid" <lunakid@neuropolis.org> wrote in message news:b67ppn$22jn$1@digitaldaemon.com...
> > > I have to second, what Matt said.
> > >
> > > Sean,
> > >
> > > > > Perhaps what is needed is an explicit conversion to bool,
> > >
> > > It should read:
> > >
> > > > > Perhaps what is needed is an explicit conversion to bool.
> > >
> > > ;)
> > >
> > > Cheers,
> > > Luna Kid
> >
> >
>
>

This would only cover half of the issue.  Assuming one wants distinct
semantic actions to replace if (o != null) {} and if (o1 == o2), this would
only address the former.

Me, I think that if (o) is a heavily established idiom, and if D isn't going to support it, it should consider it an error and prepare for the slew of complaints from people porting C code.

I'm just tossing out random ideas a lot of the time.  Brainstorming, if you will.  If I had a truly elegant solution that would address your concerns I'd post it.

Sean

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b6aqbd$1ds9$1@digitaldaemon.com...
> I agree it seems kinda nice, but how to do complex conditional, involving perhaps a couple of objects, and maybe other conditions?
>
>
>
> "Luna Kid" <lunakid@neuropolis.org> wrote in message news:b6aerf$158r$1@digitaldaemon.com...
> > Mmm... Actuall, I start liking Sean's "with" idea more and more:
> >
> >     > Or perhaps this behavior could be made part of the 'with'
statement:
> >     >
> >     > with(o)  // skips the whole block if o is null
> >     > {
> >     > }
> >
> > Luna Kid

> I'm just tossing out random ideas a lot of the time.  Brainstorming, if
you
> will.  If I had a truly elegant solution that would address your concerns I'd post it.

And the whole newsgroup would breathe a collective sigh of relief.

However, I think we should keep plugging. If you can move towards "it should consider it an error and prepare for the slew of complaints from people porting C code" then maybe anything is possible. :=))

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b6beok$1qun$1@digitaldaemon.com...
>
> Me, I think that if (o) is a heavily established idiom, and if D isn't
going
> to support it, it should consider it an error and prepare for the slew of complaints from people porting C code.

I have to agree, initially I was a bit against if ( o ) and if ( !o ) but
since I've been doing more C I find I'm writing that in D partly because
writing  if ( o === null ) is prone to me forgetting the last = and I only
write == and then get a seggy when o is null.

I had considered the if ( !!o ) but never dared to publically voice it,
you've missed the other old C idiom that I've not seen for a few years of
`if ( o = func(), o )` [I do have a C book that advises the use of if (
ptr ) oevr if ( ptr == NULL )] and I've always found `if ( NULL == ptr )` to
be ugly and a little confusing (especially when skim reading code).

I think this is quite related to the whole ==, !=, ===, !== issue. three '='
annoys me
I've been thinking that the operators for refs should be
if ( x ), if ( !x )   // null check.

if ( x == y )   // identical check (&x == &y in c++)
if ( x != y )   // not identical

if ( x $= y ) // compare values refered to  (ptrs and refs [objects])
or if ( x @= y ) // compare values refered to  (ptrs and refs [objects])
for ptrs this is the same as writing if ( *x == *y )
if ( x <> y ) // value of x is not equivilant to y

as D blurs the ptr/ref (unlike c++) allowing ptr.structmember (implicit deref) then I've not got a problem with them having a similar othe thing that always annoyed me in C++ was not being able to re-reference a reference.

I also find the range of float !<> etc operators confusing, not saying Java, C# or C are better with just one test but I have to check what he float/double cmp operators do every time I want to use them.

as for with( o ) doing a null check and ignoreing if null ...  NO I think
that is too much hidden behaviour.
however
with ( o ) {
    // do this with o if o !== null
} else {
  //  do this if o is null
}

I think is a much better solution, if the else clause if missing then it is
effectivly
`else { throw new NullPointerException(); }`

> I'm just tossing out random ideas a lot of the time.  Brainstorming, if
you
> will.  If I had a truly elegant solution that would address your concerns I'd post it.
>

likewise, I feel `!=` and `<>` are two not equiv/equal operators but I can not think of two obviously different equal to operators and dis like =, ==, === as operators, I would some days even go as far as saying = should be replaced with := to make a clear distinction between assign and compare. [or even `<-` ]

Mike Wynn wrote:
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message
> news:b6beok$1qun$1@digitaldaemon.com...
> 
>>Me, I think that if (o) is a heavily established idiom, and if D isn't
> 
> going
> 
>>to support it, it should consider it an error and prepare for the slew of
>>complaints from people porting C code.
> 
> 
> I have to agree, initially I was a bit against if ( o ) and if ( !o ) but
> since I've been doing more C I find I'm writing that in D partly because
> writing  if ( o === null ) is prone to me forgetting the last = and I only
> write == and then get a seggy when o is null.
> 
> I had considered the if ( !!o ) but never dared to publically voice it,
> you've missed the other old C idiom that I've not seen for a few years of
> `if ( o = func(), o )` [I do have a C book that advises the use of if (
> ptr ) oevr if ( ptr == NULL )] and I've always found `if ( NULL == ptr )` to
> be ugly and a little confusing (especially when skim reading code).
> 
> I think this is quite related to the whole ==, !=, ===, !== issue. three '='
> annoys me
> I've been thinking that the operators for refs should be
> if ( x ), if ( !x )   // null check.
> 
> if ( x == y )   // identical check (&x == &y in c++)
> if ( x != y )   // not identical
> 
> if ( x $= y ) // compare values refered to  (ptrs and refs [objects])
> or if ( x @= y ) // compare values refered to  (ptrs and refs [objects])
> for ptrs this is the same as writing if ( *x == *y )
> if ( x <> y ) // value of x is not equivilant to y
> 
> as D blurs the ptr/ref (unlike c++) allowing ptr.structmember (implicit
> deref) then I've not got a problem with them having a similar othe thing
> that always annoyed me in C++ was not being able to re-reference a
> reference.
> 
> I also find the range of float !<> etc operators confusing, not saying Java,
> C# or C are better with just one test but I have to check what he
> float/double cmp operators do every time I want to use them.
> 
> as for with( o ) doing a null check and ignoreing if null ...  NO I think
> that is too much hidden behaviour.
> however
> with ( o ) {
>     // do this with o if o !== null
> } else {
>   //  do this if o is null
> }
> 
> I think is a much better solution, if the else clause if missing then it is
> effectivly
> `else { throw new NullPointerException(); }`
> 
> 
>>I'm just tossing out random ideas a lot of the time.  Brainstorming, if
> 
> you
> 
>>will.  If I had a truly elegant solution that would address your concerns
>>I'd post it.
>>
> 
> 
> likewise, I feel `!=` and `<>` are two not equiv/equal operators but I can
> not think of two obviously different equal to operators and dis like =, ==,
> === as operators, I would some days even go as far as saying = should be
> replaced with := to make a clear distinction between assign and compare. [or
> even `<-` ]

Python uses the keyword 'is' where D uses ===. (and 'is not' for !==) Maybe this would be better in that it doesn't look similar to == at all. (and thus would be a lot harder to confuse)

if (o is not null) ... // more verbose, but totally unambigious.