>From: ChurlSoo Joo <xxxxxx@gmail.com>
Subject: Re: initial comments
Date: Tue, 15 Sep 2009 17:55:51 +0900

> 2.
> A method of this macro is quite different from that of CLOS.  The former is
> defined within a define-lambda-object form and only the lambda-objects of
> the
> group can access the method.  On the contrary, the latter is defined outside
> of defclass form and the method can be applied to every instance of all the
> classes.  I think the restrictiveness deserves that the methods should
> mutate
> the values of the immutable fields and this gives flexibility to the macro.

Whether you limit ways to touch a field is a matter of
encapsulation.  Whether a field can be modified or not
(mutability) is a concept orthogonal to encapsulation.

There are cases that you want to provide unlimited read
access but limited write access, so it is plausible design
choice to have some convenient ways to specify such
restriction.  But I'm afraid that using the term "immutable"
only brings confusion.

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.

--shiro