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