what the benefit is by using annotation, like "@Immutable" ?
in [Java Help]
|
Prev: Immediate Start: Need Designer's (Visual/Graphic),Beverly Hills,California,
Next: a question about alias of reference
From: Tom Anderson on 17 Jul 2010 05:36 On Fri, 16 Jul 2010, Lew wrote: > Jim Janney wrote: >>> The canonical immutable class, java.lang.String, isn't annotated as >>> immutable. > > markspace wrote: >> Hmmm: >> >> "Basic, canonic, canonical: reduced to the simplest and most significant >> form possible without loss of generality, e.g., "a basic story line"; "a >> canonical syllable pattern."" > > More like "prototypical". Paradigmatic? >> Not sure if String is "canonical" here. �Maybe "ubiquitous" is more >> what you're after. �Or possibly I just misunderstand what you mean. > > String is the most basic immutable class in the API. Object? tom -- Imagine that, the Battle of Seattle, the February Revolution, the Storming of the Bastille, the Brixton uprising, the break-in party at Hackney Town Hall and Wat Tyler's army ransacking the Tower, all at the same time.
From: Screamin Lord Byron on 17 Jul 2010 07:09 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.
From: Christian on 17 Jul 2010 08:16 > > My guess is that in the general case, any program that tries to decide > if a class is immutable will run into Rice's theorem (a.k.a. the > halting problem). Luckily even modern computers have only finite RAM ... so are only large DFAs ... and for DFAs the halting problem is decidable... ;-) (sure there is some state space explosion problem...)
From: Eric Sosman on 17 Jul 2010 08:32 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(a)ieee-dot-org.invalid
From: Lew on 17 Jul 2010 10:37
Lew writes: >> Object doesn't have attributes, so describing it as "immutable" >> runs into a triviality exception. There's nothing to change, so >> there's nothing to be immutable. String actually has attributes for Jukka Lahtinen wrote: > This makes me wonder.. if you extend an immutable class, does it require > the extending class also being immutable? No. It isn't classes that are immutable, it's instances. We say "such-and-such class is immutable" as a shamefully inaccurate colloquialism for "such-and-such class guarantees that all its instances are immutable". > If so, and Object were immutable, then EVERY class should be immutable. Object isn't immutable, objects are immutable. So when we say, "[An] Object [instance] is immutable", clearly that imposes no restrictions on subtype instances. -- Lew |