Re: what the benefit is by using annotation, like "@Immutable" ?
On 7/17/2010 7:09 AM, Screamin Lord Byron wrote:
On 07/17/2010 03:33 AM, Eric Sosman wrote:
On 7/16/2010 9:09 PM, Eric Sosman wrote:
[...] For example, Map.Entry does not satisfy the JCIP
notion of "immutable," although *I* (a person I consider reasonable)
would categorize it as such.
Well, *that's* a crock, isn't it? Map.Entry is not a class at
all, but an interface -- hence, neither "mutable" nor "immutable,"
but just "ineffable." Still: According to the JCIP criteria, no
concrete Map.Entry implementation could be considered immutable,
Are you saying that it's impossible to implement that interface in such
a way that resulting class satisfies the JCIP notion of immutable? Is it
only because of the setValue() method (for which documentation states
it's optional operation)?
while I (still semi-reasonable) think most implementations should
in fact be considered so.
I don't see any reason why those implementations wouldn't be considered
as such according to JCIP definition.
I'm so deep in the hole now that the only thing to do is
keep on digging ... Just forget my nonsense about Map.Entry --
I blundered, and then I blundered again, and my next move will
probably be to drive the blunder bus right off a cliff.
The bit of JCIP's "immutable" definition that I was trying
to call into question is the requirement that the object hold no
(accessible) references to mutable objects. That is, JCIP thinks
of an object's "state" as including not only the fields belonging
to the object itself, but all other objects that can be reached
via those fields. In JCIP's view, an object is mutable if it holds
a reference, direct or indirect, to any other mutable object; the
entire network of objects reachable from any one object is part of
that object's "state."
I think JCIP's definition is over-broad, at least in some cases.
For example, in JCIP's view an unmodifiable Set (as created, say, by
Collections.unmodifiableSet()) is mutable if the elements contained
in the set are mutable. The membership of the unmodifiable Set can't
change -- you can't add() or remove() on it -- but if a member itself
changes its own state, JCIP says this changes the Set's state. That's
a view that makes sense in some applications, but (I believe) not in
all. We can imagine a Family class, say, that we'd like to consider
immutable because our application is not concerned with births and
deaths:
class Family {
private final Set<Person> members;
Family(Person... members) {
Set<Person> set = new HashSet<Person>();
for (Person p : members)
set.add(p);
this.members = Collections.unmodifiableSet(set);
}
...
}
...
Person dad = new Person("Dad");
Person mom = new Person("Mom");
Person junior = new Person("Junior");
Person sis = new Person("Sis");
Family fam = new Family(dad, mom, junior, sis);
Now: Does `sis.earnDegree(new MBA())' change the "state" of the
Family? Is the degree an attribute of the Family, or is is solely
hers? JCIP's view is that it's both, that the Family "inherits"
(or "is contaminated by") all the attributes of all its members.
In some applications that view makes perfect sense. Sis' new
degree could affect the result of `fam.estimatedEarningPower()', for
example: it's an asset that could influence the economic outlook of
the Family as a whole. But in a genealogical application, say, the
Family may just be a repository of its Persons, and the degrees its
members hold may be of no concern -- they'll show up when you print
out the bios of a Family's members, but they're not thought of as
being familial attributes. That is, the exact same Family class can
be thought of as "mutable" in one application and "immutable" in
another, without a single line of code having changed.
I just wish I hadn't disgraced my own Family by picking such a
ridiculously bad example to start with ...
--
Eric Sosman
esosman@ieee-dot-org.invalid