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