Re: To Initialise or not

[bobduff@world.std.com (Robert A Duff)]

In article <3196FBD9.6AA1@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>Robert A Duff wrote:
>> OK, this explains our disagreement.  I would *not* be happy with such a
>> language.  You would, and would rely on default-initialization to
>> T'First.  IMHO, that just masks real bugs in the program.
>
>The part that perplexes me about this statement (other than not being able
>to figure out what kind of "bugs" are "masked"), is that it only seems to
>apply to the implicit action that occurs when an access type is declared.
>For example, do you also avoid the following constructs? If not, why not?
>
>1. Use of "others" in an aggregate expression, case statement, etc.

I don't use "others" very often.  "Others" means, to me, that I mean
to include all "other" cases, including the ones that haven't been
invented yet.  Sometimes that makes sense.

>2. Controlled types
>
>3. Dispatching
>
>4. Use of default values for components of a record type.

No, I don't avoid those.

>If you are consistent in your approach, then I can at least agree that
>you are expressing a philosophy regarding the use of the language ("no
>implicit actions, since they hide bugs." If you're not consistent,
>then I don't understand why the philosophy makes sense in some cases,
>but not others.

I'm not complaining about implicitness in general.  When I write
"others", or when I write a default value for a record component, I'm
the one writing the program and I know what I'm doing.  In the
implicit null case, Jean Ichbiah decided in 1980 that my pointers
should be initialized to null, and of course he had no idea what my
program needs today.  My point is that the programmer, not the
language designer, should be in charge of deciding whether a default
value is a good idea, and if so, what that default value should be.
The language should be in charge of detecting uninit vars.

Note that I'm not saying you should always initialize to 'null'.  I'm
perfectly happy to see "X: Some_Pointer := new Something'(...);" or
"X: Some_Pointer := Some_Other_Pointer;".

>However, I think it's "philosophy" that's backed up by experience in
>maintaining code. Have you done experiments that showed the value of adding
>extra code in this case?

No, I have no experimental evidence.

>> Let me be quite clear about what I would *like* in a language: Any type
>> that's built in to the language, and is treated as a non-composite
>> entity, should have run-time detection of uninit vars.
>
>OK. Why do you feel that you can't achieve this in Ada? With Ada 95, you
>have the ability to detect uninitialized scalars at any point in the program,
>so long as the compiler can generate a "marker" value for the object (and
>it supports the Safety and Security annex, of course).

Because (1) it only works for types don't need extra bits, and (2) not
every reference is detected.

>However, to do this consistently in Ada, you need to make a data abstraction
>for each type for which you want such protection. Just providing a redundant
>initialization fails to meet your goal.

Agreed.  But I'm not going to invent a new abstraction for indexing
Strings.  I'm going to use type Integer.

>And you stated for another case of "consistency":
>
>> Seems like a bogus argument, to me.
>> I said integers and pointers should behave the same with respect to
>> initialization.  Composites should not.
>
>Why not? Usually, consistency = simplicity, right?
>
>Note also that "consistency" in one dimension (making access values look like
>integers) can cause inconsistency in another dimension (see my discussion of
>extending your philosophy to other areas of the coding standards).

I never said "integers are exactly like access types in every
respect".  So your argument is bogus.  I just said they should be
alike with respect to detection of uninitialized vars.  (I hope we
both agree that it's good that arithmetic is available for integers,
but not for access types.)

- Bob