what is the initial value of arrays of object

[Arne Vajhøj]

A somewhat late resurrection of that thread...
Is your newsfeed late to show those articles
only now?

No - I am just behind reading.

Of course it is! The discussion wasn't about making it more
general, but about making a less general but (believed)more
common pattern syntactically simpler.

If one want to make a change then why not make it as general
as possible ?

It could be:
int[] myInts = new int[10];
{
for(int i = 0; i < myInts.length; i++) myInt = i * i + 1;
}

I dislike these nested blocks. They always make me look for
something in the previous lines, like a "for"/"if"/"while"/...
or a new SomeClass(...) (though without brackets and semicolon) -
only initializer blocks in classes are excepted, because they
happen in quite a different context.

In your example, it's even entirely unnecessary since the only
local variable in that block is already local to the "for".

And I think that is in many ways the essence.

If one want a loop, then just write a loop.

Arne

 

[Andreas Leitgeb]

(How do they do that? Do they threaten you?)

They take me by my weakness ... that of wanting to understand
the code I read.

Btw. I thought Patricia's example was meant for within code-
blocks (and that's also the context where optional braces confuse
me. initializer blocks at class level are mostly ok), but only
after some recent posts I understood, that the generality of the
idiom lies in that it can be used both within method- and class-level.

 

[Andreas Leitgeb]

Who said "local"? My code was intended for initializing a non-static
field. I agree that the braces are unnecessary, and should be removed,
when initializing a local variable.

Thanks for clarifying that. As is seems it wasn't as obvious as
it should have been, given that I was not the only one complaining
about the extra braces

 

[Andreas Leitgeb]

If one want to make a change then why not make it as general
as possible ?

Depends on the change. Some changes only make sense in a
limited scope.

If one want a loop, then just write a loop.

The premise is not met. I do not want a loop.
I only want the effect of it

 

[Patricia Shanahan]

Thanks for clarifying that. As is seems it wasn't as obvious as
it should have been, given that I was not the only one complaining
about the extra braces

The fact that it was not immediately recognized as an initializer block
suggests to me that the demand for another feature to do part of its job
may be partly due to under-use of the existing feature.

Patricia

 

[Mike Schilling]

The fact that it was not immediately recognized as an initializer
block suggests to me that the demand for another feature to do part
of its job may be partly due to under-use of the existing feature.

IMHO initializer blocks are like anonymous classes; in both, some
syntax more eye-catching than an anomalous-looking pair of braces
would add to their readability. Static initialization blocks, on the
other hand:

static
{
...
}

stand out nicely.

 

[Andreas Leitgeb]

This goes back at least to Java's roots in C, which also permits
brace-delimited statements anywhere a semicolon-terminated one can appear.

I mostly disliked (and never used) them in C and C++, either.
Had I really needed it there, I'd probably have preceded it
with an "if (1)".

 

[Andreas Leitgeb]

The fact that it was not immediately recognized as an initializer block
suggests to me that the demand for another feature to do part of its job
may be partly due to under-use of the existing feature.

Or rather due to a dislike to use an explicit for-loop for
something that "shouldn't require one" - regardless of any
braces surrounding it.

The concept itself is already there with "new int[42][42];", which
automatically populates the outer array with instances of inner arrays.
Why not also allow populating the inner arrays with other (constant)
data than null/0/false (without an explicit loop, of course) ?

PS: If there was an overloaded version of Arrays.fill for more-
dimensional arrays, that would be a compromise. Even in braces.

 

[Andreas Leitgeb]

The language features are the language features. They do what they do.
...
... They're not to be liked or disliked but used (or not used) as you
will.

Ok, lets see a few "features" of Java:

- capital I and lowercase l are different identifiers
- the Vector class (legacy, but still there, and even
facelifted(made generic) for 1.5), ditto Enumerator
- postfix "long"-literals with a lowercase "l"
- changes in indentation "without reason". Unlike
Python, Java does allow that.

Ok, you wouldn't use these "features" yourself, but see
yourself as having to work together with people who do
use them. Would you silently accept it ?

Probably not. You'd try to explain to them the disadvantages
and convince them of alternatives, the same way you do it with
people showing samples of their code here in this newsgroup
and asking questions that aren't even related to these "features".

For example, statement blocks give a convenient way to limit the
scope of a temporary variable.

But just like 42l could be mistaken for 421, a statement-block
asks for a look to the preceding context, looking for some statement
that goes with that block, just to see *if there is* one (btw., just
the same way as a sudden change of indentation-depth would).

Certainly as a code reviewer or maintainer you must be familiar
with these tools.

Yes, for sure, and as such it is almost one's duty to recognize
and discourage the use of such "features".

PS: Yes, I find standalone braced blocks just as bad as all the
other samples I gave, except for the Vector class, which I
find all ok, myself, but of which I know that you dislike it.

 

[Andreas Leitgeb]

PS: If there was an overloaded version of Arrays.fill for more-
dimensional arrays, that would be a compromise. Even in braces.

You're in luck.
<http://java.sun.com/javase/6/docs/a...ml#fill(java.lang.Object[], java.lang.Object)>

No, I'm not. It would just store that one sub-array (given as
second argument) into all the outer-array's positions. Seeing
that as the requested behaviour requires a huge amount of
misunderstanding the overall topic.

 

[Andreas Leitgeb]

In all programming languages, typographic similarities between identifiers
exist in certain fonts,

Beside the point. The real feature (no quotes) here is what
characters the identifiers or long-literals can be made of, and
indeed, most languages share this particular feature with Java.

In the same way as humans (with their highly redundant but
still low-hamming-distanced glyph-system) have difficulties
with 42l versus 421 and therefore maintain style guides to
discourage those corners, it also takes them some extra
effort telling bare braced blocks from those following certain
structural keywords.

Even well-trained Java programmers will, faced with a
braced block at the top of current scrolling-position,
no doubt scroll up a few lines to see if there is an
"if", "for", or other such keyword preceding it (unless
they already have all the source in their head already).

Of course they know that the existence of such a keyword
is not mandatory, but nevertheless they need to know
whether one is there and relevant for the block, in order
to understand the code.

 

[EJP]

This goes back at least to Java's roots in C, which also permits
brace-delimited statements anywhere a semicolon-terminated one can appear.

It goes right back to Algol 60 actually. The whole idea of
block-structured languages is that a block is equivalent to a single
statement. The use of standalone blocks falls naturally out of the
syntax. The compiler would have quite a job *not* allowing this feature.