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

Re: initial comments

This page is part of the web mail archives of SRFI 100 from before July 7th, 2015. The new archives for SRFI 100 contain all messages, not just those from before July 7th, 2015.

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".