[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: initial comments





2009/9/16, Shiro Kawai <shiro@xxxxxxxx>:
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
it "immutable".

--shiro
 
I understand what you mean.  But I have something to say.

When users are going to use a library made by *someone else*, They usually inquire *its spec* (the sequence of required and optional fields, properties of each field, function of each method, etc) in advance.  I don't think that they use the library as they ascertain its spec *through such protocols*.

Suppose I'm using a library made by *someone else*.  The library exports a class including a slot that is specified by :allocation :class.   Whenever I make an instance, I take care not to alter its value accidentally.  This is not because I knew its spec *through class-slots*,  but because I inquired its spec in advance.

--
Joo