>From: ChurlSoo Joo <xxxxxx@gmail.com>
Subject: Re: initial comments
Date: Tue, 15 Sep 2009 23:13:36 +0900

> 2009/9/15 Shiro Kawai <xxxxxx@lava.net>
>
> > ...
> >
> > What I expect when I see an immutable field is that,
> > literally, the value of the field doesn't change over
> > time, no matter what happens.  Thus I can cache the
> > value in the client side, for example.   Or I can avoid
> > locking to read the immutable fields, for no other thread
> > can possibly change their values.  It doesn't matter
> > whether the value can be changed by "private" methods
> > or not.  What matters is whether the value will ever
> > change or not.
> >
> >
> As programmers themselves can make a data field to be mutable or immutable,
> they can make a mutator-functioning method or not.

Sorry, I don't get it.  It seems irrelevant to my point.

Suppose I'm using a library made by *someone else*.
The library exports a data structure defined by define-lambda-object.
Thus, whether there's a mutator-functioning method or not
isn't under my control, and not visible to me unless I read
the source of the library.

OTOH, whether a field of the data structure is immutable
or not is visible, through (a-data-structure 'immutable-field)
protocol.  To me, it is the library implementor's contract
to its users that those fields are *immutable*, thus the
users can assume it won't change once the structure is
constructed.   At least this is my natural interpretation
when I hear something is immutable.

It is fine to have fields with a property
"only-changeable-indirectly".  I'm just against calling
it "immutable".

--shiro