After a few thoughts, I think this is a mistake not to allow this, even if it his highly discouraged.
I think indeed, if you consider the data-structure usage of types and Objects it is a very bad idea to have a mutable private field. But some type you create are not for holding data on the long-run, they are to implement an algorithm in a very local, encapsulated way. Textbooks are full of imperative algorithms that needs some type of aggregate type with mutations. Some of these algorithms are highly useful, and difficult to parallellize or write efficiently in a purely functional way. In a good program with a nice functional structure, it can happen that you want to write, inside a module, a function that implements such an algorithm. For this, you will need a way to temporary create and manipulate mutable aggregate types. Copy your data in such "ugly" data-types, and execute the imperative algorithm. What can you currently do? - Use a protocol per object/type, called with the same name with a y at the end and implement set/get for each mutable part of the aggregate. This is (very) slightly inefficient and quite ugly: double the length of the code, hide its meaning, and, worst, it pretends to have something general (a protocol) where you will only have one implantation. (The protocol is tailored to mirror the type you created.) - Use atoms inside a immutable type. It is a bit less efficient but slightly less ugly. Anyway, it still makes the code less straightforward to read. - Write a java file. It is very annoying for future portability and it does not seem like a long-term solution. As an illustration of my point, you can have a look at the n-body implantation for the shootout: http://shootout.alioth.debian.org/u32q/program.php?test=nbody&lang=clojure&id=2 Half the file is full of trivial, non reusable, interface definitions and implementation. My idea is that, if we were to write a program with planets, we would write something nice, using Clojure immutable data-types and references, and agent, and the like. And the deftype for a Body in the shootout, wouldn't be very suitable. But if somewhere in this big-program, we want to write a function that compute the solution of a n-body problem, we won't have the choice, we would need to copy the objects in ugly but efficient data-structures and implement the fast algorithm. Nobody would advocate that it's not the thing to do for Matrix computations, and the array family of functions is here for that. Why favours linear algebra algorithms (first class, can be efficiently written in straightforward Clojure) with respect to other imperative algorithm? I am sure people would use such an option wisely, if it has a sufficiently worrying name. Sorry for the long explanation, I hope it made my point clearer. Best regards, Nicolas. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
