>> 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
--
http://mail.python.org/mailman/listinfo/python-list
