A Collections Framework?
in [Lisp]
|
Prev: scheme problem
Next: lisp student job offer
From: Scott L. Burson on 24 May 2010 18:14 On May 24, 3:12 am, Norbert_Paul <norbertpauls_spam...(a)yahoo.com> wrote: > Scott L. Burson wrote: > > As I am working in Java now for my day job, I am working on code that > > has been written using the Javacollections. And I noticed the other > > day a place where an object A, which has a collection in one of its > > slots, was returning that collection through a getter, and a second > > object B was calling that getter and then modifying the returned > > collection. E.g.: > > > class A { > > List<Something> children; > > List<Something> getChildren() { return children; } > > } > > > class B { > > void mumble(A a) { > > aKids = a.getChildren(); > > // ... > > aKids.set(someIdx, someNewKid); > > // ... > > } > > } > > > What's wrong with this, of course, is that it breaks class A's > > abstraction boundary. Such behavior is a likely source of bugs. > > Why does it so? The intented abstraction should be documented, and > I can imagine very well, that exposing the List-object could be > intented. > > children may very well be > > children = new List<Something>(){ > // override List-modifications here thus ensuring invariants. > }; I'm not quite sure what you're suggesting here. Where would this code appear? > How do you prevent these bugs in Lisp? How would you then write > get-children? Oh, you have to understand, Pascal and I are grinding orthogonal axes :) I'm not so much attacking Java as I am arguing for functional collections. Before FSet, Lisp was weak in this area as well, though not quite as weak as Java because lists are in fact often used functionally (though nothing enforces this). I just wrote about Java because I did happen across this example in a real-world Java program, and I think Java encourages this kind of thing somewhat more than Lisp does. At least, in Lisp, if all you do with a list is to call CONS on it, you're not going to damage it; there's no corresponding thing you can do with a collection in Java except to clone it and mutate the clone. > AFAIK in MOP you have access to the class precedence list > and could even destructively modify it, which, of course, is > forbidden by the spec but need not be checked, surely due to > efficiency reasons. That's a good example, actually. In Lisp you have to "just know" that you shouldn't do things like that. > Should a language prevent bugs by removing features? I'm not suggesting any features be removed. In fact, as far as Java goes, I want to see features added: I want to see pure (immutable) versions of the collection interfaces added as superinterfaces of the existing ones. Then, when returning a collection owned by an object, I could return it as the pure type; the client then couldn't modify it (at least not without downcasting it to the mutable type, but at that point it's clearly not accidental). From the point of view of the client of that interface, I suppose you could say a feature has been removed, because the client can no longer modify the collection. But the program as a whole has been improved. Besides, my proposal would not force anyone to use the pure interfaces when that was inappropriate. > Bad programmer's habits are not an issue of a language. Oh, I don't agree at all. Languages should encourage good habits. > > Like most things in programming, it depends on what you're doing. If > > your primary focus is on algorithms, functional collections may not > > seem to have any clear advantages. But really, relatively few of us > > spend most of our time on the relatively small but CPU-intensive > > pieces of code that go by the name of algorithm. Most of us, I think, > > spend most of our time on much larger pieces of code, one of our > > primary tasks being the management of complexity. And when it comes > > to managing complexity, I argue that functional collections have clear > > advantages that more than offset their minor performance cost. > > Yes, but my particular interest with which I started this thread was > what goes by the name of algorithm. I know. But as thread drift goes, this seems pretty minor :) -- Scott |