On 13 October 2010 14:37, Reinier Zwitserloot <[email protected]> wrote:
> Well, my argument was exactly the opposite: There is *NO* clear
> understanding of what Immutable is supposed to mean. Sure, we can all
> agree that this:
>
> @Data public class Point {
> private final int x, y;
> }
>
> is clearly and undeniably immutable (and all its methods are SEF and
> Unchanging, too), but the borderline where things are grey and some
> deem a class immutable while others don't is rather large:
> java.io.File
It isn't, although parts of the class that represent a path reference could
be, if factored out.
> that tricky weak hashmap situation
Does it have something in it that can change after construction?
If so, then it isn't immutable.
> read-only wrappers around collections
Can any of the methods ever return different values in subsequent calls when
supplied with the same arguments?
If so, then it isn't immutable.
> the general issues with java.util not actually
> supporting immutability at all (at least not on the type level)
>
True, it's a big problem. Google-collections helps, but we really need some
of that thinking pushed back into the library.
Right now, the only interfaces suitable for immutability are Iterable and
Iterator. Even Collection has an add() method.
> scaling old code (what if I hold a reference to an object of a type
> that is immutable, but because its old isn't marked as such?), and
> many more.
>
Why is it wrong to hold a reference to an immutable object without flagging
it as such? It's still just an object!
In the future, yes, I can imagine APIs that will only accept immutable
objects. But we don't have them yet, so this needn't be a concern.
> I'm not trying to argue against the idea of @Immutable in general; on
> the contrary, I'd like java to have such a device. I'm trying to argue
> that including it in JDK7 is extremely premature. These things need to
> be sorted out. I'm also trying to argue that @SEF and @Unchanging,
> being far better defined, might be more useful. After all, if
> @Immutable is not compiler-enforced, then we must assume mistakes are
> made that are not going to be tested appropriately, and this in turn
> means that tooling that makes use of @Immutable annotations is going
> to have to deal with the fact that developers have different ideas of
> what @Immutable even means. That sounds like it would significantly
> weaken the utility of the diagnostics provided by such checker tools.
There's a crucial distinction between side-effect-free and immutability here
that seems to be at the root of any possible confusion.
side-effect-freedom is a property of Functions (or methods, if you prefer).
Immutability is a property of values (both objects and primitives, but
they're always immutable)
If applicable to just objects, @Immutable can only ever mean the same thing
as your proposed @Unchanging annotation.
The corresponding annotation for methods would be @Pure
(@ReferentiallyTransparent is more formally correct, but also too
long-winded)
Yes, @Pure could also be a class-level annotation, to avoid having to add it
to every method. But this is just a convenience, and isn't
some inherent quality of the class itself.
> On Oct 13, 10:30 am, Graham Allan <[email protected]> wrote:
> > Hey,
> >
> > I'd say this kind of pattern falls in that last 5% of cases where
> > static analysis tool authors are justified in saying "Well, yeah,
> > instances of that class are technically immutable, but meh, you're
> > doing weird stuff". That may not be a good enough view to take for a
> > compiler, but I think it's fair and useful for "ACME Static Tool". The
> > most common cases (e.g. accidentally adding a setter method) are where
> > most of the benefits lie. Also, in this domain, a false positive is a
> > much better prospect than a false negative.
> >
> > IMO there's enough of an understanding of what's intended with
> > @Immutable, that we should just agree to use one annotation, and let
> > the tools and knowledge revolve around it. But yeah, I can see how
> > that would be really messy :-)
> >
> > Regards,
> > Graham
> >
> > On Oct 12, 5:25 pm, Reinier Zwitserloot <[email protected]> wrote:
> >
> >
> >
> >
> >
> >
> >
> > > Perhaps now is a good time to show off this little snippet just to
> > > highlight how nigh-impossible it is to track immutability:
> >
> > > public class SeeminglyImmutablePointer {
> > > private static final Map<SeeminglyImmutablePointer, Object> map =
> > > new MapMaker().weakKeys().makeMap();
> >
> > > public void set(Object val) {
> > > map.put(this, val);
> > > }
> > > public Object get() {
> > > return map.get(this);
> > > }
> >
> > > }
> >
> > > Note that @SEF and @Unchanging have no problem with this snippet; a
> > > compiler can clearly determine that set is not SEF, and that get() is,
> > > and it can also determine that set() is unchanging (trivially - any
> > > method with return type void will have that property), and that get
> > > isn't.
>
> --
> 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]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
--
Kevin Wright
mail / gtalk / msn : [email protected]
pulse / skype: kev.lee.wright
twitter: @thecoda
--
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.
