On Fri, Nov 5, 2010 at 11:40 PM, Ben Karel <[email protected]> wrote: > I'm looking forward to seeing the rest of this train of thought. One > question, though: > > Mark Miller has argued that mutability within a data structure is a matter >> of protecting internal integrity, and that expressing things as constraints >> on mutability is therefore the wrong model. > > > Wrong in what sense? >
Morally. (Just kidding) > Insufficiently expressive, or conceptually at the wrong level, or just > fundamentally the wrong notion for providing encapsulation and integrity? > Some mix of these. First, "read only" doesn't provide encapsulation, and it provides only very weak integrity. But second, he argues that it's the wrong conceptual model. Let me try to re-capture my conversation with him. Our discussion started because I was trying to sort out what it means to be a read-only field contained in a mutable structure. If "a" is mutable, but "a.b" is immutable, what does that mean? Clearly, the location that is denoted by a.b is mutable, since a as a whole can be overwritten. And in consequence, the expression a.b isn't a term! So what is it, then, that we want here? Why does the programmer impose controls on the b field specifically? Mark argues (and I agree) that this is really an integrity/correctness issue. What the programmer is trying to express is that there is some constraint on the a.b field that must be maintained in order for the a object to be semantically sensible. Actually, there are lots of possible constraints, one of which is that the a.b field must not change during the lifetime of a. But note that when we conceptualize the problem in this way -- that is: as an integrity matter -- we soon conclude that immutability isn't the right idea here; what we really want is a general way to constrain updates to the fields. That is a matter of protection and encapsulation. Those things can be used to enforce integrity. OK. So I think I believe all of that, but then what is the role of [im]mutability in fields (if any)? The first answer seems obvious: immutability prevents assignment. But given encapsulation, we can accomplish that much by suitably controlling the methods on the object. The second answer is more subtle: immutability tells us that certain operational results on objects may be cached *provided* the object itself does not change. That is: (a) the operation producing the result is non-mutating, and (b) the operation does not observe (source) any state that is mutable by any *other* operation. Informally, I would say that an immutable field is one that cannot change after the initialization of the object. But the more general notion is the idea of a "pure" operation on the object - one whose result is durable in the sense that I describe with properties (a, b) above. Tagging a field as mutable is a (very) convenient common case, but it isn't the core of the issue. On the other hand, identifying pure operations is not necessarily straightforward. The obvious next question is: what's the right model for enforcing > encapsulation? > I agree that this is the obvious next question, but let's stick with one issue at a time. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
