immutable is a heavily overloaded term. I would guess that dick is referring to immutable references (final fields) pointing to immutable objects.
I've done this myself, and later regretted it, as I wanted to dynamically calculate a field lazily after a version rev, which wasn't possible. All things being equal though, making a double immutable public is not nearly as prohibitive to API revving as doing the same to mutables. On Nov 21, 1:40 am, Christian Catchpole <[email protected]> wrote: > I don't know specifically what dick was talking about, but my concerns > are: > > - does this give you dual methodologies for field access? members vs > getters > > - a reference may be final (maybe immutable) now, but what do you do > if your class evolves to where the reference is now mutable? > > - even though a field is final can the caller still modify the > object? I guess you can argue the same for any getter though. > > On Nov 21, 10:02 am, Moandji Ezana <[email protected]> wrote: > > > > > At his Devoxx talk, Dick casually mentioned that making final fields public > > was now a best practice. I do this sometimes on my non-work projects, but > > feel a little dirty. I doubt it would fly at work. > > > I thought it was too trivial a point to bring up as a question after the > > talk, but what do you guys think? Is making final fields public acceptable? > > > Moandji -- 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=.
