First of all: I tend to use "final" a lot, up to the point that I in
Eclipse-based projects I configure the automatic addition of all
flavours of "final" as a save action (i.e. happens whenever I save). I'm
not a full hardliner on the topic in that I would allow exceptions
depending on taste, but I think the default should be the final variant.
But I think the danger of misunderstanding the "final" on a parameter is
quite real. The problem to me is that Java does a pretty good job of
hiding the notion of a reference and while in theory a number of
modifiers apply to the reference, the "final" is the only one I can
think of where the distinction between reference and the object referred
to matters.
I would even go as far as claiming that adding a way of explicitly
denoting object immutability would make Java easier to understand since
it would force people into being aware of both. People tend to think of
adding features as always adding complexity, but in this case I believe
it would only make existing complexity visible, which is a step forward.
Peter
On Sat, 2009-02-14 at 11:56 -0500, Robert Fischer wrote:
> 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.
>
> That danger (assuming we define mutability as a danger) is just as there with
> or without final. So
> there is no swapping of dangers: just the elimination of one danger (which
> was previously there),
> but not all dangers. Final prevented you from writing code like this and
> accidentally expecting it
> to work the way your code did before:
>
> private static void updatePerson(Person p)
> {
> /*
> Insert a bunch of code noise and branches here.
> */
> p = new Person()
> /*
> Insert a bunch of code noise and branches here.
> */
> p.setName("Billy");
> }
>
> ~~ Robert Fischer.
> Grails Training http://GroovyMag.com/training
> Smokejumper Consulting http://SmokejumperIT.com
> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
> Check out my book, "Grails Persistence with GORM and GSQL"!
> http://www.smokejumperit.com/redirect.html
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
