Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Why mutable/immutable can't be valid class qualifier?

Reply
Thread Tools

Why mutable/immutable can't be valid class qualifier?

 
 
hiwa
Guest
Posts: n/a
 
      03-07-2006
I used to be uneasy at the fact that immutability
of a class object is only casually mentioned in
some tiny corner of the API documentation.

And I wonder why we can't do:

public immutable class BigDecimal

or, implementing a marker inteface:

public class BigDecimal
All Implemented Interfaces:
Immutable, Serializable, Comparable<BigDecimal>

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      03-07-2006


hiwa wrote On 03/07/06 04:36,:
> I used to be uneasy at the fact that immutability
> of a class object is only casually mentioned in
> some tiny corner of the API documentation.
>
> And I wonder why we can't do:
>
> public immutable class BigDecimal
>
> or, implementing a marker inteface:
>
> public class BigDecimal
> All Implemented Interfaces:
> Immutable, Serializable, Comparable<BigDecimal>


Probably because "immutable" can be hard to pin down
satisfactorily. Example:

final class ImmutableThing {

// these members are assumed immutable, too:
private final SomeThing x;
private final OtherThing y;
private final ThirdThing z;

ImmutableThing() {
x = new SomeThing("surprise");
y = new OtherThing("fear");
z = new ThirdThing("there is no third thing");
}

public boolean equals(Object obj) {
if (! (obj instanceof ImmutableThing))
return false;
ImmutableThing that = (ImmutableThing)obj;
return x.equals(that.x) && y.equals(that.y)
&& z.equals(that.z);
}

private int lazyHash; // computed only if needed

public int hashCode() {
if (lazyHash == 0) {
// do the expensive hashing only once
laxyHash = x.hashCode() ^ y.hashCode()
^ z.hashCode();
}
return lazyHash;
}
}

The crucial question: Is this class immutable? One
argument says it's not, because the lazyHash member's value
can change after construction. Another argument says that
doesn't matter, because lazyHash can only be observed by
calling hashCode() and hashCode() returns a constant value.
Both are right, in their own terms -- and how are you going
to define the semantics of a keyword or marker interface so
as to make both sides happy? If you can't, how will you
placate those on the unhappy side?

There's quite a lot about Java that lives solely in the
documentation. For instance, the compiler would accept

class Stupid implements Comparable {
public int compareTo(Object obj) {
return 42;
}
}

Only the JavaDoc tells us that this does not fulfill the
contract of the Comparable interface; the compiler is not
aware of the contract and so cannot enforce it. Immutabilty
(both the quality itself and the sense in which it is to be
understood for the class at hand) is a similar case. Or as
a colleague once observed, "The compiler is not a substitute
for self-discipline."

--
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
 
 
 
Oliver Wong
Guest
Posts: n/a
 
      03-07-2006

"Eric Sosman" <(E-Mail Removed)> wrote in message
news:dukfar$9pt$(E-Mail Removed)...
>
> Probably because "immutable" can be hard to pin down
> satisfactorily. Example:
>
> final class ImmutableThing {
>
> // these members are assumed immutable, too:
> private final SomeThing x;
> private final OtherThing y;
> private final ThirdThing z;
>
> ImmutableThing() {
> x = new SomeThing("surprise");
> y = new OtherThing("fear");
> z = new ThirdThing("there is no third thing");
> }
>
> public boolean equals(Object obj) {
> if (! (obj instanceof ImmutableThing))
> return false;
> ImmutableThing that = (ImmutableThing)obj;
> return x.equals(that.x) && y.equals(that.y)
> && z.equals(that.z);
> }
>
> private int lazyHash; // computed only if needed
>
> public int hashCode() {
> if (lazyHash == 0) {
> // do the expensive hashing only once
> laxyHash = x.hashCode() ^ y.hashCode()
> ^ z.hashCode();
> }
> return lazyHash;
> }
> }
>
> The crucial question: Is this class immutable? One
> argument says it's not, because the lazyHash member's value
> can change after construction. Another argument says that
> doesn't matter, because lazyHash can only be observed by
> calling hashCode() and hashCode() returns a constant value.
> Both are right, in their own terms


Excellent example. Here's another one which shows why a class which may
appear to be immutable to the compiler, but appears to NOT be immutable to
the user.

<pseudocode>
class FakeImmutable {
private final FileWriter out;
private final FileReader in;

public FakeImmutable() {
File f = createTempFile("fake","immutable");
out = new FileWriter(f);
in = new FileReader(f);
}

public synchronized String getX() {
/*Read from the in, and return whatever you got.*/
}

public synchronized void setX(String newValue) {
/*Clear the file, and write the newValue to the file.*/
}
}
</pseudocode>

From the compiler's perspective, this is an immutable class. That is,
all of its fields are final (constant). But from the user's perspective, it
appears to have a field called X which is settable.

- Oliver

 
Reply With Quote
 
hiwa
Guest
Posts: n/a
 
      03-08-2006
Eric Sosman wrote:
> Probably because "immutable" can
> be hard to pin down satisfactorily.


Oliver Wong wrote:
> immutable to the compiler, but appears
> to NOT be immutable to the user


Well, then, what could be the definition or criteria
Java API documentation uses when they call a class
object immutable? There must be one, not two or more.

 
Reply With Quote
 
Oliver Wong
Guest
Posts: n/a
 
      03-08-2006

"hiwa" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> Eric Sosman wrote:
>> Probably because "immutable" can
>> be hard to pin down satisfactorily.

>
> Oliver Wong wrote:
>> immutable to the compiler, but appears
>> to NOT be immutable to the user

>
> Well, then, what could be the definition or criteria
> Java API documentation uses when they call a class
> object immutable? There must be one, not two or more.


They mean "from the user's perspective". That is, there does not exist a
sequence of calls that the user can make so that the apparent state of the
object changes.

Note that using the definition I just gave, Eric's example is immutable,
but mine is not. The *INTERNAL* state of Eric's example changes, but the
apparent state does not. So it is immutable.

Whereas in my example, the INTERNAL state does not change, but the
apparent state does change, so my class is not immutable (even though all of
its fields are declared final).

The basic conclusion is that humans can decide whether a class is
immutable or not, but a compiler can't. That is why there isn't an
"immutable" keyword for classes.

- Oliver

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why a class can't access protected method from another class in thesame package,the method is interited from the ohtner class from differntpackage? junzhang1983@gmail.com Java 3 01-28-2008 02:09 AM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Nested Class, Member Class, Inner Class, Local Class, Anonymous Class E11 Java 1 10-12-2005 03:34 PM
A parameterized class (i.e. template class / class template) is not a class? christopher diggins C++ 16 05-04-2005 12:26 AM



Advertisments