Vince,
"final" always refers to the reference, not the object. What the final
disallows is assigning a new reference to the parameter, in your example
e.g. doing a:
private static void updatePerson(final Person p)
{
p = new Person("Billy");
}
With the "final" modifier this is disallowed. Without the "final" it is
allowed, but the scope of the change will be limited to the method,
which means that the main method will still see the Andrew version.
What you would need to support your notion of not changing is an
immutable object (or "const object" in C++ lingua). Java doesn't have
those, which is a real bummer since they are much more useful than
immutable references.
The whole way in which Java treats references as first-class entities is
IMO confusing and I strongly believe that you are part of a majority of
Java developers who don't really understand this use of "final" or why
Java is technically always pass-by-value on parameters. There is
certainly a gap between what I would consider a natural conceptual model
and what Java does.
Cheers,
Peter
On Fri, 2009-02-13 at 23:56 -0800, Vince O'Sullivan wrote:
> This is a pleasant change. A discussion about Java and not
> TheNewLanguageOfTheWeek.
>
> I'm a pretty lightweight programmer compared with you guys, so I tried
> the following snippet of code to see what effect the final keyword
> would have..
>
> public static void main(String[] args)
> {
> Person p = new Person(); // A simple class with a single
> property.
> p.setName("Andrew");
> System.out.println(p.getName());
> updatePerson(p);
> System.out.println(p.getName());
> }
>
> private static void updatePerson(final Person p)
> {
> p.setName("Billy");
> }
>
> Output:
> Andrew
> Billy
>
> My simple (perhaps even simplistic) conclusion is that the final
> keyword has not added any protection but has added the false
> appearance of protection. All that has happened is that the dangers
> of getting things wrong through not using final have been swapped for
> different dangers of getting things wrong when using final.
> Personally, I'd be inclined to use Occam's razor and keep things
> simple by not adding keyword that are only partially effective, stick
> with the common idiom and rely on tests, not coding style, to prove
> the code.
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
