Re: programming concepts > specific languages




"Gerry Quinn" <gerryq@xxxxxxxxxxxxxxxxxxx> wrote in message
news:MPG.1ddbf09eb09f1b5198a73f@xxxxxxxxxxxxxxxxx
> In article <SL4cf.96645$y_1.52289@edtnps89>, owong@xxxxxxxxxxxxxx
> says...
>> Because of the topic we're discussing, the terminology has to be very
>> precise here. Strings are immutable. So are integers. You didn't change
>> the
>> string. You changed the referenced named "stringToManipulate" to point to
>> a
>> DIFFERENT string. Whereas it used to point to the string "ABC", it now
>> points to the string "DEF". The original string "ABC" has not be
>> modified,
>> as you said.
>>
>> There is actually no secret "new" involved because of the way Java
>> optimizes Strings by allocating them once in a static allocator upon
>> class
>> load and re-uses Strings.
>
> In other words, a secret 'new', except that it is done on class
> loading.

Like I said, we're starting to nitpick here, so I'd like for the
terminology to be very precise. To call what happens in class loading a
'new' operation is misleading. I'm willing to let this simplifying
assumption slide for now, and say "Okay, fine, if you want to call it a
'secret new', then go ahead", but if you later on use this as an argument
for Java's pass by value system being inconsistent, I'll have to retract
that statement and start talking about what really happens at class loading.

>
>> Java does treat Strings specially: Since they are
>> used to frequently in programs, they are one of the most heavily
>> optimized
>> objects, sometimes "cheating" and having direct hooks into the Java
>> Virtual
>> Machine to speed up processing. I didn't think this was going to become
>> an
>> issue, but since it seems to have become so, why don't we switch to using
>> the Integer class instead? e.g.:
>>
>> integerToManipulate = new Integer(5);
>> objectToManipulate.x = 10;
>
> The issue doesn't come up here because there is no secret 'new'
> involved with the Integer class. You could not have made the case you
> were trying to make using Java's inconsistent String class.

The case I was trying to make is that Java always passes by value.
Whether or not a "new" is involved (nevermind whether that new is "secret"
or not) seems to be irrelevant to me (whether a new object is created, or
the same object is used, method calls still use pass by value), but since
this is the point you want to get addressed, I'm addressing it.

>
>> > In the second case there is no secret 'new' because Object is mutable
>> > and I am allowed change the object to which a reference is passed.
>>
>> That is not "why" there is no secret "new". The Integer class is
>> immutable as shown in the new code snippet above, and the "new" there
>> cannot
>> be made "secret". The secretness or non-secretness of the "new" has
>> nothing
>> to do with immutability and has to do with virtual machine optimizations.
>
> The 'new' is there because of immutability. It is secret because of
> Java's inconsistency.

That is not *WHY* the "new" is there. You use the "new" keyword for
instantiating a class, regardless of whether the instances of that class are
mutable or not. And to say it (the "new" with regards to Strings) is secret
*BECAUSE* of Java's inconsistency is very misleading. Do you honestly
believe the designers of Java said to themselves "Hmm, since Java is
inconsistent, we'd better make the 'new' secret"? I think it happened more
like "Hmm, it'd be nice if Strings had syntactic sugar so that they could be
treated like primitives instead of Objects."

At the very most, you could take the position of "Java is inconsistent
because Strings have syntactic sugar so that they can be treated like
primitives". Every statement you have made about "secret news" has either
been a result of misunderstanding on your part of how Java Strings work (and
you seem to refuse to accept corrections to your misunderstanding), or just
intentional FUD spreading.

>> Primitives, objects and mutability are "off topic" with regards to my
>> original claim, which I'm requoting here:
>>
>> <quote>
>> Java has consistent, but non-intuitive, rules involving passing by
>> value/passing by reference.
>> </quote>
>>
>> Note that while I believe that Java is consistent in other areas
>> (including in the areas of primitives, objects and mutability), that was
>> not
>> the claim I was trying to debate, so it's somewhat frustrating to see you
>> steer the conversation in this new direction without addressing the
>> original
>> claim.
>
> I steered it in that direction because you made incorrect claims to
> which they are relevant. You used String rather than Integer because
> the 'new' is secret. If the 'new' were explicit, arguments such as:
>
> QUOTE:
> << On the second line, the value of the reference is passed along, not
> the address, so the second method receives "54" and not "3". Therefore,
> it cannot ever actually modify the contents of memory location 3, and
> therefore it cannot ever change what object the "myString" reference
> points to. >>
>
> ..implying that the contents of address 54 could be altered, would be
> obviously meaningless.

Alright, so I made a mistake in choosing a poor example. I still believe
the original claim is accurate though. Will you allow me to give a new
example while maintaining the original claim?

- Oliver


.