[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: initial comments
From: ChurlSoo Joo <initerm@xxxxxxxxx>
Subject: Re: initial comments
Date: Tue, 15 Sep 2009 23:13:36 +0900
> 2009/9/15 Shiro Kawai <shiro@xxxxxxxx>
> > ...
> > 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