Dive Into Java?

[Diez B. Roggisch]

>> For example: the overloading of assignment operators, casting
>> operators, copy constructors and the like that, and the fact that
>> one of them is possibly chosen in absence of the other.
> 
> Isn't the overloading concept an effect of type strength? In Java,
> you'd have to overload them too. Or am I missing something?


Yes. You can for example create a constructor for object Foo, which then is
implicitly chosen when assigning an int to a variable of that kind. So it
acts as a casting operator. I call that wicked, and subtle.

class Foo {
  int _arg;
public:
  Foo(int arg) {
    _arg = arg;
  }
};

int main() {
  Foo f = 10;
}

  
>> The subtle differences between pointers and references.
> 
> That's an issue, though you don't have to use them both. Kind
> of "historically grown".

Who cares for the reason - it is there, isn't it? You are the one claiming
that a new language should get rid of old concepts, btw. Where is your
money, and where your mouth?
  
>> Missing definition of static initializer order, at least for some
>> binary formats.
> 
> Didn't come across this one though.

I did when doing embedded programming. bites you, especially in such an
environment.

> Example:
> 
> int spam = 5;
> 
> but
> 
> String eggs = new String();
> 
> The latter seems totally unnecessary to me, as well as being too
> verbose -- why couldn't they go the simple way as in Python and
> just state
> 
> String eggs;

The unfortunate separation between primitive (read: numbers) and complex
types (everything else) is a stupid idea, I agree. However, that is
remedied with 1.5, and beyond the odd corner case in a very well matter
(see below.)

> That's a wrong decision, IMHO. A new and practical language (what
> Java wanted to be) shouldn't provide 3/4-compatible syntax, but be
> clear, concise and customizable, and shouldn't say "That's bad, you
> mustn't do that."

That is a matter of taste - but in the same way, we could argue about C++
and C, can't we? And it "just" took the very basic things - building
blocks, control flow and classes.
 
>> You are confusing things here. That you can't implement your own
>> string derived class has to do with java.lang.String being final -
>> something I grief about, too.
> 
> That's not exactly my point. What if I just wanted to build my own
> interface compatible class ... impossible.

I don't understand that.

> For a start, it just doesn't look pretty ...
> 
> String ham;
> 
> ham = "1" + "2";
> 
> ... is translated to ...
> 
> ham = new StringBuffer().append("1").append("2").toString()


So what? Since when is compiler optimization a bad thing? What do you think
happens all the time when mixing types in C++? And I know of some very
elaborated schemes called "common base class idiom" for e.g. template-based
vector classes to introduce allocation optimization to arithmetic
expressions in C++.

The code _generated_ by the java compiler, and the C++ compiler, is not the
issue here. If you as a programmer can write "a" + "b", its fine. Which is
a thing to reach in C++, a bazillion of string-classes have been
written....


and in C++, you can do:

char *a = "1";
char *b = "2";
char *c = a + b;

But with a totally different, unexpected outcome.. I know where *I* start
laughing here.

> Another funny thing are those awkward wrapper classes, but that's
> been "patched" in an awkward way with 1.5 IIRC.

The way is not awkward, it is called auto-boxing/unboxing and works very
well. The odd corner case being e.g.

Boolean b = null;
if(b) { // NPE here
}

 
And this is more than matched by the subtle differences between

Foo a;
Foo &a;
Foo *a;

Diez