final on objects

Thread view:

Matthias Kaeppler - 16 Jun 2005 18:21 GMT

Hi,

is it normal that the compiler doesn't complain
when I execute a modifying method on a final object?
Does final only mean that the object simply isn't
being modified?

I'm coming from the C++ camp, and there you have
no chance to call non-const methods on const
objects without getting a compile time error.

Thanks,
Matthias

Reply to this Message

Johan Poppe - 16 Jun 2005 18:48 GMT

Matthias Kaeppler wrote:

>is it normal that the compiler doesn't complain
>when I execute a modifying method on a final object?
>Does final only mean that the object simply isn't
>being modified?

What do you mean with a final object?

If a class is final, it cannot be subclassed.

If a variable is final, it cannot be changed. But if the variable is a
reference type, the object it refers to can still be changed. So if a
variable is declared and initialized with
final Bar myBar = new Bar();

then this is perfectly legal:
myBar.setSomething(42);

However, this is not legal:
myBar = new Bar();

If you want to object itself to be immutable, you must change the code
defining that class. (There was a long discussion here recently about
exactly what loop you have to jump trough to make a class immutable.
You may want to google that.)

Signature

Johan Utne Poppe

Reply to this Message

Matthias Kaeppler - 17 Jun 2005 08:12 GMT

> then this is perfectly legal:
> myBar.setSomething(42);
[quoted text clipped - 6 lines]
> exactly what loop you have to jump trough to make a class immutable.
> You may want to google that.)

That's what I meant, thanks.

Signature

Matthias Kaeppler

Reply to this Message

Alan Krueger - 16 Jun 2005 22:16 GMT

> Hi,
>
[quoted text clipped - 4 lines]
> I'm coming from the C++ camp, and there you have no chance to call
> non-const methods on const objects without getting a compile time error.

Java final != C++ const

Reply to this Message

John Currier - 17 Jun 2005 01:05 GMT

> I'm coming from the C++ camp, and there you have
> no chance to call non-const methods on const
> objects without getting a compile time error.

Unless things have changed significantly in C++ in the past 7 years
(when I jumped ship to Java) you can cast away the "constness" of an
object and call away.

John

Reply to this Message

Matthias Kaeppler - 17 Jun 2005 08:11 GMT

>>I'm coming from the C++ camp, and there you have
>>no chance to call non-const methods on const
[quoted text clipped - 5 lines]
>
> John

Ouch. Yes, you can do a lot of stupid things in C++ :)

Signature

Matthias Kaeppler

Reply to this Message

Owen Jacobson - 18 Jun 2005 07:43 GMT

>> I'm coming from the C++ camp, and there you have no chance to call
>> non-const methods on const objects without getting a compile time error.
[quoted text clipped - 4 lines]
>
> John

Doing anything non-const with a formerly-const value after
const_cast<T>ing it away is either implementation defined or simply
undefined. The cast exists for interoperability with pre-standard code
that abuses const in some fashion.

Anyways, final isn't const. Final just means that a value won't change:
try to change the value of a final reference in Java and it'll complain,
but change the referenced object all you want.

Reply to this Message

John Currier - 20 Jun 2005 05:09 GMT

> Doing anything non-const with a formerly-const value after
> const_cast<T>ing it away is either implementation defined or simply
> undefined. The cast exists for interoperability with pre-standard code
> that abuses const in some fashion.

Can it be both "undefined" and "exists for interoperability" without
interoperability being undefined?

I remember having to cast away consts whenever I called what you refer
to as pre-standard code, but that code didn't abuse const...it just
didn't know anything about it because const didn't exist when the code
was written.

John

Reply to this Message

final on objects

Free Magazines