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



Well, apart from it *being* sensible syntax (e.g. when x is boolean), I'd like to stress another point.

Terseness is a very valid and important goal - it is one of
the most important properties of an all-around language. Some
of it should, naturally, be traded off for other valid goals,
like readability (see PERL for a bad-balance example, or Eiffel,
on the "too verbose" end to some).

Since

        if (x is initialized)

            do something with x

        else

            do error handling

is among the most common coding idioms, one cannot ignore the relief the short if (x) form gives to one's fingers. It's not at all just an unfortunate accident that the syntax allows it in so many practical languages - instead, the opposite is true: the support is well worse the risks.

However, it is also true, that there could be much better ways to support that idiom, than tweaked "if" statements...

Using e.g. exception handling (in languages where it's convenient to use) the above can be rewritten to something like:

        try

            something with x

        else if (x is not initialized)    // "catch"

            do error handling

Exceptions, however, are practical only for heavier cases,
where e.g. errors can arise at multiple points etc. Exceptions
are *not* optimal (both in terms of readability and efficiency)
for the simplest and (therefore?) most frequent cases, where
a single "if" would also do perfectly.

So
    - for the very frequent simple cases exceptions give you
      nothing but unnecessary overhead

    - legacy code will be never rewritten from

                "if (x is initialized)"
      to
                "catch (x is not initialized)"

      in order to use exception handling just because it's
      available and is considered "modern style"

DbC invariant would also be much better, but they are just impossible, or non-trivial, or too much work to add for simple, built-in types.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

About initializations....

In short: practice sadly blurs the two completely different concepts, but "being zero" is NOT THE SAME THING as "being uninitialized". (But I guess most of you are well aware of this classic problem of automatic zero-init.) Even, "being uninitialized because of a bug" or "not got a valid value by run-time input" are two subtly different things.

Now, unfortunately, as the "ideal language" is still yet to be defined, there is no standard, clear and explicit notation for

        if (initialized x)

            do something with x

        else

            do error handling

programmers, when handling the above-mentioned different cases, fall back "randomly" to various techniques available in the language they usewith whatever available (some form of an "if" caluse, exception handling, assertions or other invariant checking (DbC stuff) etc.).

Some languages - implicitly - support this fallback (e.g. with
imlicit conversion to bool and supporting the short if(x) form),
some others pretend as if the need to express briefly that
"if x is OK" never existed in the real world, forcing the
fallback more painful than necessary (e.g. by saying "use
exceptions" or "compare x to some value" or "define an
is_initialized() boolean function").

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

So, to sum it up... The "Right Thing" for coding the simple and very frequent case of "checking the usability of an object before use" would be *explicitly* supported by a good language, in some dedicated way. The "ideal language" would acknowledge that objects tend to be in "usable" and "unusable" states.

It would go further than silently encouraging programmers
writing "if (x)"...

Thanks,
Luna Kid

> > 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 ...
>
>
> Well, apart from it *being* sensible syntax (e.g. when x is boolean), I'd like to stress another point.

I mean: ...x is boolean, or if there is a sensible
default conversion to boolean. (I would not dare to
deny the usefulness of default type coercion in a
practical imperative programming language...)

Luna Kid

Since the vast bulk of my experience is C & C++, I am coming from that perspective (where implicit conversions are both easy and nasty). My experience (and I have a lot of it in terms of clearing up other people's messes) informs me that both these languages should follow Java's lead in the boolean-ness of conditional expressions. I do this myself as a matter of habit, and it does not impede the speed of my development; I still write code _very_ quickly, but more safely and, as I emphasised before, much more *maintainably*. That's the important part of it.

To the degree we are discussing it, terseness is an irrelevance. What matters is correctness, clarity  and maintainability. People with a lot more weight and "name" in the industry than little old me have documented war stories up to their armpit. I mean no discourtesy to you (or anyone else who espouses your point of view), but I find that programmers who do, or have done, a lot of maintenance and/or trouble-shooting & remediation are unaninmous in their willingness to sacrifice terseness (not to mention the odd right arm) for correctness, clarity and maintainability.

I am a little surprised that a language that seeks to make it hard to do the hard mistakes of other languages, and makes it impossible to do the simple mistakes, passes the book on this point. I'm not advocating a nannying language, such as Java - printf() is well worth the risk - but boolean conditionals seems to be such a good reward for such a little sacrifice.

However, we are debating needlessly. I know full well that I've got more chance of persuading Microsoft to write a standards-compliant Java compiler than I have in persuading the vast bulk of developers to accept extra typing when they deem it's not needed.

To satisfy everyone, perhaps all we need is an optional compiler warning -
in the
vein of DMC++s -wc - that tells us about it. (And the ability to promote it
to an error, of course). Walter, I imagine this would be pretty easy to do?

"Luna Kid" <lunakid@neuropolis.org> wrote in message news:b64rc4$4m3$1@digitaldaemon.com...
> > > 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 ...
>
>
>
> Well, apart from it *being* sensible syntax (e.g. when x is boolean), I'd like to stress another point.
>
> Terseness is a very valid and important goal - it is one of
> the most important properties of an all-around language. Some
> of it should, naturally, be traded off for other valid goals,
> like readability (see PERL for a bad-balance example, or Eiffel,
> on the "too verbose" end to some).
>
> Since
>
>         if (x is initialized)
>
>             do something with x
>
>         else
>
>             do error handling
>
> is among the most common coding idioms, one cannot ignore the relief the short if (x) form gives to one's fingers. It's not at all just an unfortunate accident that the syntax allows it in so many practical languages - instead, the opposite is true: the support is well worse the risks.
>
> However, it is also true, that there could be much better ways to support that idiom, than tweaked "if" statements...
>
> Using e.g. exception handling (in languages where it's convenient to use) the above can be rewritten to something like:
>
>         try
>
>             something with x
>
>         else if (x is not initialized)    // "catch"
>
>             do error handling
>
> Exceptions, however, are practical only for heavier cases,
> where e.g. errors can arise at multiple points etc. Exceptions
> are *not* optimal (both in terms of readability and efficiency)
> for the simplest and (therefore?) most frequent cases, where
> a single "if" would also do perfectly.
>
> So
>     - for the very frequent simple cases exceptions give you
>       nothing but unnecessary overhead
>
>     - legacy code will be never rewritten from
>
>                 "if (x is initialized)"
>       to
>                 "catch (x is not initialized)"
>
>       in order to use exception handling just because it's
>       available and is considered "modern style"
>
> DbC invariant would also be much better, but they are just impossible, or non-trivial, or too much work to add for simple, built-in types.
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> About initializations....
>
> In short: practice sadly blurs the two completely different concepts, but "being zero" is NOT THE SAME THING as "being uninitialized". (But I guess most of you are well aware of this classic problem of automatic zero-init.) Even, "being uninitialized because of a bug" or "not got a valid value by run-time input" are two subtly different things.
>
> Now, unfortunately, as the "ideal language" is still yet to be defined, there is no standard, clear and explicit notation for
>
>         if (initialized x)
>
>             do something with x
>
>         else
>
>             do error handling
>
> programmers, when handling the above-mentioned different cases, fall back "randomly" to various techniques available in the language they usewith whatever available (some form of an "if" caluse, exception handling, assertions or other invariant checking (DbC stuff) etc.).
>
> Some languages - implicitly - support this fallback (e.g. with
> imlicit conversion to bool and supporting the short if(x) form),
> some others pretend as if the need to express briefly that
> "if x is OK" never existed in the real world, forcing the
> fallback more painful than necessary (e.g. by saying "use
> exceptions" or "compare x to some value" or "define an
> is_initialized() boolean function").
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> So, to sum it up... The "Right Thing" for coding the simple and very frequent case of "checking the usability of an object before use" would be *explicitly* supported by a good language, in some dedicated way. The "ideal language" would acknowledge that objects tend to be in "usable" and "unusable" states.
>
> It would go further than silently encouraging programmers
> writing "if (x)"...
>
> Thanks,
> Luna Kid
>
>

Well, to avoid guessing whether I'm yet another daily
coder who fetishizes expressions shorter by a few chars,
just because they are shorter by a few chars -- I just
assure you: I'm not from that camp. :)

> To the degree we are discussing it, terseness is an irrelevance. What matters is correctness, clarity  and maintainability. People with a

Let's not diverge from our specific subject to generailties
we all agree on. :) (One comment, still: I've learned (you
bet: from maintenance work), that terseness is not necessarily
evil. Actually, verbosity tends to also very often introduce
or increase diversity, which definitely *is* bad. Terse code
-- not in the cryptic PERL way --, can actually help
understanding it. (You can see e.g. windowsx.h vs. MFC (I
mention those because you are familiar with them), both
doing good and bad in this matter.) So, it is never black
and white.

The problem is, that good balance between verbosity and
readability (and maintainability) is utterly subjective.
(And, as you also also know, "the perfect language" is
just another Holy Grail.)

Back to the point...

What I intended to state in my messy post, was that if people write things like

            if (f)
or even

            f && write(...

or even (truly horrible) things like

            if (f = fopen...

they do it not because they are stupid and never heared about maintenance etc. They don't probably enjoy shooting themselves in the foot, either. (Some surely do, but let's not focus our discussion on how dumb people do things). What they do, is simply using idioms. Quite common and practical idioms, I have to add (for the first two).

But, what I also implied -- and that's actually the whole point of my message -- that it is a poor, suboptimal, risky and hacky way of doing that! So, welcome to your own club, Matt! :)

What I would like to see in a "dream language", is using
if (...) for checking normal boolean stuff (as defined e.g.
in C++), *and* some facilities to express the idioms you
see all around, but in some *clean* manner. In a cleaner
way, than they are expressed now, being those crippled
if(x) statements.

But that is difficult. It leads over to the muddy land
of initializations and leads directly into the middle of
religious battles over default values, zero values, empty
states, invariants and their checking etc. etc. Libraries
can be filled with papers written on this topic, too.

All I say is, that because this is a subtle and complex matter, ignoring the whole phenomenon, or regarding it as just stubborn and incomprehensibly stupid reluctance for typing those extra chars, is, well, probably not the most correct and/or constructive approach, in my opinion.


> To satisfy everyone, all we need is an optional compiler warning - in the vein of DMC++s -wc - that tells us about it. (And the ability to promote
it

No. That's symptomatic treatment, leaving you sick but
not complain as much (the compiler doing it for you...).

What *really* is needed is proper built-in semantics and syntax for letting you express what you mean by

    if (f) ...

so people won't write this difficult-to-digest construct, but write something cleaner. Now, don't ask me what that should be... Something that is convenient, and maps directly to the semantics of the above idiom:

    if (f is OK)

What this "OK" is -- man, this war between the USA and
Iraq is just a friendly chat compared to what a debate
on this matter could be...

Cheers,
Luna Kid


----- Original Message -----
From: "Matthew Wilson" <matthew@synesis.com.au>
To: "Luna Kid" <lunakid@neuropolis.org>
Sent: 2003. március 29. 23:48
Subject: Re: On "if (x)" and initialization...


> Since the vast bulk of my experience is C & C++, I am coming from that perspective (where implicit conversions are both easy and nasty). My experience (and I have a lot of it in terms of clearing up other people's messes) informs me that both these languages should follow Java's lead in the boolean-ness of conditional expressions. I do this myself as a matter
of
> habit, and it does not impede the speed of my development; I still write code _very_ quickly, but more safely and, as I emphasised before, much
more
> *maintainably*. That's the important part of it.
>
> To the degree we are discussing it, terseness is an irrelevance. What matters is correctness, clarity  and maintainability. People with a lot
more
> weight and "name" in the industry than little old me have documented war stories up to their armpit. I mean no discourtesy to you (or anyone else
who
> espouses your point of view), but I find that programmers who do, or have done, a lot of maintenance and/or trouble-shooting & remediation are unaninmous in their willingness to sacrifice terseness (not to mention the odd right arm) for correctness, clarity and maintainability.
>
> I am a little surprised that a language that seeks to make it hard to do
the
> hard mistakes of other languages, and makes it impossible to do the simple mistakes, passes the book on this point. I'm not advocating a nannying language, such as Java - printf() is well worth the risk - but boolean conditionals seems to be such a good reward for such a little sacrifice.
>
> However, we are debating needlessly. I know full well that I've got more chance of persuading Microsoft to write a standards-compliant Java
compiler
> than I have in persuading the vast bulk of developers to accept extra
typing
> when they deem it's not needed.
>
> To satisfy everyone, all we need is an optional compiler warning - in the vein of DMC++s -wc - that tells us about it. (And the ability to promote
it
> to an error, of course). Walter, I imagine this would be pretty easy to
do?
>
>
> ----- Original Message -----
> From: "Luna Kid" <lunakid@neuropolis.org>
> Newsgroups: D
> Sent: Sunday, March 30, 2003 5:18 AM
> Subject: On "if (x)" and initialization...
>
>
> > > > 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 ...
> >
> >
> >
> > Well, apart from it *being* sensible syntax (e.g. when x is boolean), I'd like to stress another point.
> >
> > Terseness is a very valid and important goal - it is one of
> > the most important properties of an all-around language. Some
> > of it should, naturally, be traded off for other valid goals,
> > like readability (see PERL for a bad-balance example, or Eiffel,
> > on the "too verbose" end to some).
> >
> > Since
> >
> >         if (x is initialized)
> >
> >             do something with x
> >
> >         else
> >
> >             do error handling
> >
> > is among the most common coding idioms, one cannot ignore the relief the short if (x) form gives to one's fingers. It's not at all just an unfortunate accident that the syntax allows it in so many practical languages - instead, the opposite is true: the support is well worse the risks.
> >
> > However, it is also true, that there could be much better ways to support that idiom, than tweaked "if" statements...
> >
> > Using e.g. exception handling (in languages where it's convenient to use) the above can be rewritten to something like:
> >
> >         try
> >
> >             something with x
> >
> >         else if (x is not initialized)    // "catch"
> >
> >             do error handling
> >
> > Exceptions, however, are practical only for heavier cases,
> > where e.g. errors can arise at multiple points etc. Exceptions
> > are *not* optimal (both in terms of readability and efficiency)
> > for the simplest and (therefore?) most frequent cases, where
> > a single "if" would also do perfectly.
> >
> > So
> >     - for the very frequent simple cases exceptions give you
> >       nothing but unnecessary overhead
> >
> >     - legacy code will be never rewritten from
> >
> >                 "if (x is initialized)"
> >       to
> >                 "catch (x is not initialized)"
> >
> >       in order to use exception handling just because it's
> >       available and is considered "modern style"
> >
> > DbC invariant would also be much better, but they are just impossible, or non-trivial, or too much work to add for simple, built-in types.
> >
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > About initializations....
> >
> > In short: practice sadly blurs the two completely different concepts, but "being zero" is NOT THE SAME THING as "being uninitialized". (But I guess most of you are well aware of this classic problem of automatic zero-init.) Even, "being uninitialized because of a bug" or "not got a valid value by run-time input" are two subtly different things.
> >
> > Now, unfortunately, as the "ideal language" is still yet to be defined, there is no standard, clear and explicit notation for
> >
> >         if (initialized x)
> >
> >             do something with x
> >
> >         else
> >
> >             do error handling
> >
> > programmers, when handling the above-mentioned different cases, fall back "randomly" to various techniques available in the language they usewith whatever available (some form of an "if" caluse, exception handling, assertions or other invariant checking (DbC stuff) etc.).
> >
> > Some languages - implicitly - support this fallback (e.g. with
> > imlicit conversion to bool and supporting the short if(x) form),
> > some others pretend as if the need to express briefly that
> > "if x is OK" never existed in the real world, forcing the
> > fallback more painful than necessary (e.g. by saying "use
> > exceptions" or "compare x to some value" or "define an
> > is_initialized() boolean function").
> >
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > So, to sum it up... The "Right Thing" for coding the simple and very frequent case of "checking the usability of an object before use" would be *explicitly* supported by a good language, in some dedicated way. The "ideal language" would acknowledge that objects tend to be in "usable" and "unusable" states.
> >
> > It would go further than silently encouraging programmers
> > writing "if (x)"...
> >
> > Thanks,
> > Luna Kid
> >
> >
>

Clarifications:

1. I absolutely agree that too much verbosity is also bad, and concede that not acknowledging that is a failing in my posts so far. Indeed, I find review & remediation of Java more of a challenge than C++ in this regard, although it's perhaps offset by the fact that the number of stuff-ups available in Java is (at least a bit) smaller.

2. I would like to stipulate that I wasn't calling any person stupid, or seeking to imply that anyone is. I often comment that certain things are stupid, but _never_ personalise things, especially on a Digital Mars group. ;) That's just plain bad manners.

3. The idioms are only such because the language allows bad practise. I cannot believe that any experienced practitioner (of C++, at least) has not come across a conditional expression that they have not readily comprehend due to terseness of form, and further assert that I cannot accept that the same experienced practitioners have not been bitten by the meaning of implicit conversion operators.

What does

 string  line;

 while(s >> line)

mean, when s is an iostream input stream instance? I don't know! Every time
I see such thing I have to run to see whether operator void *() means
good(), or not bad(), or not eof(), or not eof() AND not bad(), or blah blah
blah all the way back to the drawing board. Heaven's above, if having
operator void *() used to denote a boolean state doesn't get people's alarm
bells ringing, I'm going to take up ornate pastry making, and leave this
game to those who clearly grok a picture my feeble brain can never hope to
comprehend!

Anyway, I'm going to shut up, as I've been doing far too much pontificating over the last couple of days, and nowhere near enough work. ("Hear, hear" you all cry. ;)

I'm primarily a coper, rather than an idealist, so if Walter'll give me the compiler switch to warn of non-boolean conditional expressions, I'll promise never to darken the door of this subject again. Over to you, big W ...


"Luna Kid" <lunakid@neuropolis.org> wrote in message news:b65rpn$qh9$1@digitaldaemon.com...
> Well, to avoid guessing whether I'm yet another daily
> coder who fetishizes expressions shorter by a few chars,
> just because they are shorter by a few chars -- I just
> assure you: I'm not from that camp. :)
>
> > To the degree we are discussing it, terseness is an irrelevance. What matters is correctness, clarity  and maintainability. People with a
>
> Let's not diverge from our specific subject to generailties
> we all agree on. :) (One comment, still: I've learned (you
> bet: from maintenance work), that terseness is not necessarily
> evil. Actually, verbosity tends to also very often introduce
> or increase diversity, which definitely *is* bad. Terse code
> -- not in the cryptic PERL way --, can actually help
> understanding it. (You can see e.g. windowsx.h vs. MFC (I
> mention those because you are familiar with them), both
> doing good and bad in this matter.) So, it is never black
> and white.
>
> The problem is, that good balance between verbosity and
> readability (and maintainability) is utterly subjective.
> (And, as you also also know, "the perfect language" is
> just another Holy Grail.)
>
> Back to the point...
>
> What I intended to state in my messy post, was that if people write things like
>
>             if (f)
> or even
>
>             f && write(...
>
> or even (truly horrible) things like
>
>             if (f = fopen...
>
> they do it not because they are stupid and never heared about maintenance etc. They don't probably enjoy shooting themselves in the foot, either. (Some surely do, but let's not focus our discussion on how dumb people do things). What they do, is simply using idioms. Quite common and practical idioms, I have to add (for the first two).
>
> But, what I also implied -- and that's actually the whole point of my message -- that it is a poor, suboptimal, risky and hacky way of doing that! So, welcome to your own club, Matt! :)
>
> What I would like to see in a "dream language", is using
> if (...) for checking normal boolean stuff (as defined e.g.
> in C++), *and* some facilities to express the idioms you
> see all around, but in some *clean* manner. In a cleaner
> way, than they are expressed now, being those crippled
> if(x) statements.
>
> But that is difficult. It leads over to the muddy land
> of initializations and leads directly into the middle of
> religious battles over default values, zero values, empty
> states, invariants and their checking etc. etc. Libraries
> can be filled with papers written on this topic, too.
>
> All I say is, that because this is a subtle and complex matter, ignoring the whole phenomenon, or regarding it as just stubborn and incomprehensibly stupid reluctance for typing those extra chars, is, well, probably not the most correct and/or constructive approach, in my opinion.
>
>
> > To satisfy everyone, all we need is an optional compiler warning - in
the
> > vein of DMC++s -wc - that tells us about it. (And the ability to promote
> it
>
> No. That's symptomatic treatment, leaving you sick but
> not complain as much (the compiler doing it for you...).
>
> What *really* is needed is proper built-in semantics and syntax for letting you express what you mean by
>
>     if (f) ...
>
> so people won't write this difficult-to-digest construct, but write something cleaner. Now, don't ask me what that should be... Something that is convenient, and maps directly to the semantics of the above idiom:
>
>     if (f is OK)
>
> What this "OK" is -- man, this war between the USA and
> Iraq is just a friendly chat compared to what a debate
> on this matter could be...
>
> Cheers,
> Luna Kid
>
>
> ----- Original Message -----
> From: "Matthew Wilson" <matthew@synesis.com.au>
> To: "Luna Kid" <lunakid@neuropolis.org>
> Sent: 2003. március 29. 23:48
> Subject: Re: On "if (x)" and initialization...
>
>
> > Since the vast bulk of my experience is C & C++, I am coming from that perspective (where implicit conversions are both easy and nasty). My experience (and I have a lot of it in terms of clearing up other
people's
> > messes) informs me that both these languages should follow Java's lead
in
> > the boolean-ness of conditional expressions. I do this myself as a
matter
> of
> > habit, and it does not impede the speed of my development; I still write code _very_ quickly, but more safely and, as I emphasised before, much
> more
> > *maintainably*. That's the important part of it.
> >
> > To the degree we are discussing it, terseness is an irrelevance. What matters is correctness, clarity  and maintainability. People with a lot
> more
> > weight and "name" in the industry than little old me have documented war stories up to their armpit. I mean no discourtesy to you (or anyone else
> who
> > espouses your point of view), but I find that programmers who do, or
have
> > done, a lot of maintenance and/or trouble-shooting & remediation are unaninmous in their willingness to sacrifice terseness (not to mention
the
> > odd right arm) for correctness, clarity and maintainability.
> >
> > I am a little surprised that a language that seeks to make it hard to do
> the
> > hard mistakes of other languages, and makes it impossible to do the
simple
> > mistakes, passes the book on this point. I'm not advocating a nannying language, such as Java - printf() is well worth the risk - but boolean conditionals seems to be such a good reward for such a little sacrifice.
> >
> > However, we are debating needlessly. I know full well that I've got more chance of persuading Microsoft to write a standards-compliant Java
> compiler
> > than I have in persuading the vast bulk of developers to accept extra
> typing
> > when they deem it's not needed.
> >
> > To satisfy everyone, all we need is an optional compiler warning - in
the
> > vein of DMC++s -wc - that tells us about it. (And the ability to promote
> it
> > to an error, of course). Walter, I imagine this would be pretty easy to
> do?
> >
> >
> > ----- Original Message -----
> > From: "Luna Kid" <lunakid@neuropolis.org>
> > Newsgroups: D
> > Sent: Sunday, March 30, 2003 5:18 AM
> > Subject: On "if (x)" and initialization...
> >
> >
> > > > > 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 ...
> > >
> > >
> > >
> > > Well, apart from it *being* sensible syntax (e.g. when x is boolean), I'd like to stress another point.
> > >
> > > Terseness is a very valid and important goal - it is one of
> > > the most important properties of an all-around language. Some
> > > of it should, naturally, be traded off for other valid goals,
> > > like readability (see PERL for a bad-balance example, or Eiffel,
> > > on the "too verbose" end to some).
> > >
> > > Since
> > >
> > >         if (x is initialized)
> > >
> > >             do something with x
> > >
> > >         else
> > >
> > >             do error handling
> > >
> > > is among the most common coding idioms, one cannot ignore the relief the short if (x) form gives to one's fingers. It's not at all just an unfortunate accident that the syntax allows it in so many practical languages - instead, the opposite is true: the support is well worse the risks.
> > >
> > > However, it is also true, that there could be much better ways to support that idiom, than tweaked "if" statements...
> > >
> > > Using e.g. exception handling (in languages where it's convenient to use) the above can be rewritten to something like:
> > >
> > >         try
> > >
> > >             something with x
> > >
> > >         else if (x is not initialized)    // "catch"
> > >
> > >             do error handling
> > >
> > > Exceptions, however, are practical only for heavier cases,
> > > where e.g. errors can arise at multiple points etc. Exceptions
> > > are *not* optimal (both in terms of readability and efficiency)
> > > for the simplest and (therefore?) most frequent cases, where
> > > a single "if" would also do perfectly.
> > >
> > > So
> > >     - for the very frequent simple cases exceptions give you
> > >       nothing but unnecessary overhead
> > >
> > >     - legacy code will be never rewritten from
> > >
> > >                 "if (x is initialized)"
> > >       to
> > >                 "catch (x is not initialized)"
> > >
> > >       in order to use exception handling just because it's
> > >       available and is considered "modern style"
> > >
> > > DbC invariant would also be much better, but they are just impossible, or non-trivial, or too much work to add for simple, built-in types.
> > >
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > About initializations....
> > >
> > > In short: practice sadly blurs the two completely different concepts, but "being zero" is NOT THE SAME THING as "being uninitialized". (But I guess most of you are well aware of this classic problem of automatic zero-init.) Even, "being uninitialized because of a bug" or "not got a valid value by run-time input" are two subtly different things.
> > >
> > > Now, unfortunately, as the "ideal language" is still yet to be defined, there is no standard, clear and explicit notation for
> > >
> > >         if (initialized x)
> > >
> > >             do something with x
> > >
> > >         else
> > >
> > >             do error handling
> > >
> > > programmers, when handling the above-mentioned different cases, fall back "randomly" to various techniques available in the language they usewith whatever available (some form of an "if" caluse, exception handling, assertions or other invariant checking (DbC stuff) etc.).
> > >
> > > Some languages - implicitly - support this fallback (e.g. with
> > > imlicit conversion to bool and supporting the short if(x) form),
> > > some others pretend as if the need to express briefly that
> > > "if x is OK" never existed in the real world, forcing the
> > > fallback more painful than necessary (e.g. by saying "use
> > > exceptions" or "compare x to some value" or "define an
> > > is_initialized() boolean function").
> > >
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > So, to sum it up... The "Right Thing" for coding the simple and very frequent case of "checking the usability of an object before use" would be *explicitly* supported by a good language, in some dedicated way. The "ideal language" would acknowledge that objects tend to be in "usable" and "unusable" states.
> > >
> > > It would go further than silently encouraging programmers
> > > writing "if (x)"...
> > >
> > > Thanks,
> > > Luna Kid
> > >
> > >
> >
>
>

"Luna Kid" <lunakid@neuropolis.org> writes:

> What I would like to see in a "dream language", is using
> if (...) for checking normal boolean stuff (as defined e.g.
> in C++), *and* some facilities to express the idioms you
> see all around, but in some *clean* manner. In a cleaner
> way, than they are expressed now, being those crippled
> if(x) statements.

So you want a clean idiom which expresses "this object is ok"?

Make it a rule that things that can be either ok or non-ok include a "valid()" member function.  This means for starters all reference type objects.  I don't mean that valid() should be an overridable member function of Object, but rather a final and inlined one, so that it wouldn't bloat the vtable and cause any run-time overhead.

class Object
{
  final bit valid()
  {
    return this != null;
  }
}

This will make the programmer's intention as clear as possible:

Object f();

g()
{
  Object o = f();

  if (o.valid())
    use(o);
  else
    dont_use_it();
}

So, valid() is equivalent to comparison with null, except that it's semantically simpler and more straightforward:

- checking for validity is, in my opinion, simpler concept than
  checking for non-equivalence or possibly non-identity with null
- there's only one way to write it, whereas you can compare with
  equivalence to null in 4 ways:
  - if (o != null)
  - if (o !== null)
  - if (null != o)
  - if (null !== o)
  (And in production code you will most certainly see all of these...)

This is idiom is also often used with other things that can be invalidated, such as iterators:

f(int_iterator ii)
{
  while (ii.valid())
    print(ii.get_next());
}

Naturally, iterators should be structs in that case, so that their
valid() member function wouldn't be confused with Object.valid().

One of the major downsides of this kind of valid() is, indeed, that it
cannot be used with classes that already have a member function
valid().  It would be possible to define valid() as a function which
first checks for null and then calls user-defined valid() if the class
has one.  This would, however, add further complication to the
language.  (Although in that, it would be similar to the null-checking
"=="...)

-Antti

"Matthew Wilson" <dmd@synesis.com.au> writes:

> habit, and it does not impede the speed of my development; I still write code _very_ quickly, but more safely and, as I emphasised before, much more *maintainably*. That's the important part of it.

You're quite on the right track when talking about maintainability.

When you encounter the line

  if (hilavitkutin != null)

you indeed know instantly that hilavitkutin is a reference type.  And when you see

  if (kalapala != 0)

it's perfectly clear that the variable is an integer one, not to mention things like

  if (!some_input_stream.eof())

So this kind of verbosity should be definitely encouraged in code that is to be read by someone.

But the compiler (or IDE, or whatever) has the access to the type information, so why doesn't it transform to less readable, terse code to more readable and maintainable code automatically, as a side effect of the compilation?  Why must the burden of annotating the code with redundant information be left to the programmer?

Suppose that you have file test.d (and also suppose that if (o) was
legal) and you compile it:

test.d (before compilation):

void f(Object o)
{
  if (o)
    use(o);
}

then you compile it -- execute yourfancydcompiler test.d -- and it changes copies test.d to test.d.orig and makes a new test.d:

test.d (after compilation):

void f(Object o)
{
  if (o != null)
    use(o);
}

It's the small things that make the perfect development environment, right?

-Antti

[Comments embedded.]

----- Original Message -----
From: "Antti Sykari" <jsykari@gamma.hut.fi>
Newsgroups: D
Sent: 2003. március 30. 13:30
Subject: Re: On "if (x)" and initialization...


> So, valid() is equivalent to comparison with null, except that it's semantically simpler and more straightforward:
>...

Yes, basically that's it. It just raises a few small annoying
questions to me. One, as you noted, is its name (let's assume
it's easy -- well, but to find a short, nice, non-obtrusive
one...). Then, is it OK to restrict the thing to classes?
("if (str)" is all too common.) Also, doing == null is too
restrictive, as validity is context dependent (str.empty() may
mean invalid, even if str != null), etc.

But I'm really starting to think that my idea for a dedicated syntax was quite superfluous. The more I think about it, the better I like the _existing_ "if (x)" construct...

At least I have no problem decoding it, and it is prefectly expressive to me, once I manage to memorize this "heretic" rule (which many other C++ "sinners" find a joy to obey to): an object is valid, if it's true in a boolean context...

Er, what exactly was the problem with this?...

Cheers,
Luna Kid

> [Comments embedded.]

(Hehh, my mail was like 3 times longer and uglier, when I put
the line up there... :) I stole that nice notation from Daniel
Yokomiso, by the way.")

Perhaps what is needed is an explicit conversion to bool, or an explicit nonzero / non-null check.

Wait, we already have it!  It's called '!!'.

Object o = someobj;
if (!!o)
{
    o.Print();
}

If you want to disallow implicit conversion to bool, at least keep the '!' operator so we can do this trick, which is still terse, yet explicit.  I argue that it's *not* that hard to read.  Once you've seen it once you will know the idiom.

Unless someone has an idea for another operator that means explicit check if non-null?

I'm not that against some other statement construct for this purpose, either:

if_valid(o)
{
}

Or perhaps this behavior could be made part of the 'with' statement:

with(o)  // skips the whole block if o is null
{
}

Sean



"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b65qho$pqk$1@digitaldaemon.com...
> Since the vast bulk of my experience is C & C++, I am coming from that perspective (where implicit conversions are both easy and nasty). My experience (and I have a lot of it in terms of clearing up other people's messes) informs me that both these languages should follow Java's lead in the boolean-ness of conditional expressions. I do this myself as a matter
of
> habit, and it does not impede the speed of my development; I still write code _very_ quickly, but more safely and, as I emphasised before, much
more
> *maintainably*. That's the important part of it.
>
> To the degree we are discussing it, terseness is an irrelevance. What matters is correctness, clarity  and maintainability. People with a lot
more
> weight and "name" in the industry than little old me have documented war stories up to their armpit. I mean no discourtesy to you (or anyone else
who
> espouses your point of view), but I find that programmers who do, or have done, a lot of maintenance and/or trouble-shooting & remediation are unaninmous in their willingness to sacrifice terseness (not to mention the odd right arm) for correctness, clarity and maintainability.
>
> I am a little surprised that a language that seeks to make it hard to do
the
> hard mistakes of other languages, and makes it impossible to do the simple mistakes, passes the book on this point. I'm not advocating a nannying language, such as Java - printf() is well worth the risk - but boolean conditionals seems to be such a good reward for such a little sacrifice.
>
> However, we are debating needlessly. I know full well that I've got more chance of persuading Microsoft to write a standards-compliant Java
compiler
> than I have in persuading the vast bulk of developers to accept extra
typing
> when they deem it's not needed.
>
> To satisfy everyone, perhaps all we need is an optional compiler warning -
> in the
> vein of DMC++s -wc - that tells us about it. (And the ability to promote
it
> to an error, of course). Walter, I imagine this would be pretty easy to
do?
>
> "Luna Kid" <lunakid@neuropolis.org> wrote in message news:b64rc4$4m3$1@digitaldaemon.com...
> > > > 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 ...
> >
> >
> >
> > Well, apart from it *being* sensible syntax (e.g. when x is boolean), I'd like to stress another point.
> >
> > Terseness is a very valid and important goal - it is one of
> > the most important properties of an all-around language. Some
> > of it should, naturally, be traded off for other valid goals,
> > like readability (see PERL for a bad-balance example, or Eiffel,
> > on the "too verbose" end to some).
> >
> > Since
> >
> >         if (x is initialized)
> >
> >             do something with x
> >
> >         else
> >
> >             do error handling
> >
> > is among the most common coding idioms, one cannot ignore the relief the short if (x) form gives to one's fingers. It's not at all just an unfortunate accident that the syntax allows it in so many practical languages - instead, the opposite is true: the support is well worse the risks.
> >
> > However, it is also true, that there could be much better ways to support that idiom, than tweaked "if" statements...
> >
> > Using e.g. exception handling (in languages where it's convenient to use) the above can be rewritten to something like:
> >
> >         try
> >
> >             something with x
> >
> >         else if (x is not initialized)    // "catch"
> >
> >             do error handling
> >
> > Exceptions, however, are practical only for heavier cases,
> > where e.g. errors can arise at multiple points etc. Exceptions
> > are *not* optimal (both in terms of readability and efficiency)
> > for the simplest and (therefore?) most frequent cases, where
> > a single "if" would also do perfectly.
> >
> > So
> >     - for the very frequent simple cases exceptions give you
> >       nothing but unnecessary overhead
> >
> >     - legacy code will be never rewritten from
> >
> >                 "if (x is initialized)"
> >       to
> >                 "catch (x is not initialized)"
> >
> >       in order to use exception handling just because it's
> >       available and is considered "modern style"
> >
> > DbC invariant would also be much better, but they are just impossible, or non-trivial, or too much work to add for simple, built-in types.
> >
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > About initializations....
> >
> > In short: practice sadly blurs the two completely different concepts, but "being zero" is NOT THE SAME THING as "being uninitialized". (But I guess most of you are well aware of this classic problem of automatic zero-init.) Even, "being uninitialized because of a bug" or "not got a valid value by run-time input" are two subtly different things.
> >
> > Now, unfortunately, as the "ideal language" is still yet to be defined, there is no standard, clear and explicit notation for
> >
> >         if (initialized x)
> >
> >             do something with x
> >
> >         else
> >
> >             do error handling
> >
> > programmers, when handling the above-mentioned different cases, fall back "randomly" to various techniques available in the language they usewith whatever available (some form of an "if" caluse, exception handling, assertions or other invariant checking (DbC stuff) etc.).
> >
> > Some languages - implicitly - support this fallback (e.g. with
> > imlicit conversion to bool and supporting the short if(x) form),
> > some others pretend as if the need to express briefly that
> > "if x is OK" never existed in the real world, forcing the
> > fallback more painful than necessary (e.g. by saying "use
> > exceptions" or "compare x to some value" or "define an
> > is_initialized() boolean function").
> >
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > So, to sum it up... The "Right Thing" for coding the simple and very frequent case of "checking the usability of an object before use" would be *explicitly* supported by a good language, in some dedicated way. The "ideal language" would acknowledge that objects tend to be in "usable" and "unusable" states.
> >
> > It would go further than silently encouraging programmers
> > writing "if (x)"...
> >
> > Thanks,
> > Luna Kid
> >
> >
>
>