Dive Into Java?

Diez B. Roggisch deets at nospam.web.de
Wed Oct 11 20:34:44 CEST 2006

Bjoern Schliessmann schrieb:
> Diez B. Roggisch wrote:
>> 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;
>> }
> Just looks like Java's
> String spam = "eggs";

You don't seem to understand what is happening here. The fact that 
string literals in java exist has nothing to do with an implicit type 
casting as above example shows.

>> 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.
> Is C++ new? :) IIRC it's well 10 years older than Java, and that's
> quite a lot in IT. Apart from this, Java is constantly evolving
> (through Sun), where C++ is quite a standard since <= 1998.

C++ was new, nobody forced them to keep pointers around.

> If I'd like to write a class that is interface compatible to Java's
> String, so e.g. that I can use it with "+" operator or the
> simplified construction (String a = "b";).

That isn't possible with python, too. It _is_ possible with C++, yes, as 
my own example above shows, but at the cost of complex semantics.

And the +-operator can be used when you have a toString-method.

> I don't offense compiler optimization, but the clunkiness of
> those "special rules for String only" additions.

Python has those clunky rules as well as C++ - or don't you write 
character literals like


in C++ as well? Where exactly is that clunky?

>> The way is not awkward, it is called auto-boxing/unboxing and
>> works very well. 
> But it looks weird. Why not use classes for basic types? Is
> performance really the reason? It kind of splits the language
> style.

For the same reason ints and floats aren't objects _internally_ in C++ 
as well - optimization. C++ did go a better way here by treating ints as 
objects syntactically, but the distinction is most of the times removed 
from java as well since 1.5.

> And this is more than matched by the subtle differences between
>> Foo a;
>> Foo &a;
>> Foo *a;
> I don't think that's too subtle. But, perhaps, just because I'm used
> to C++. It has a little bit too many compatibility features.
> But I'd rather like to have several options than being forced in one
> way.

But choices let you make more errors - which was my point from the 
beginning: java is a limited language, and I don't like it too much. But 
it makes it hard to do things wrong. C++ makes it hard to make them right.


More information about the Python-list mailing list