Clojure record constructors not first class?

Question

Apparently, you can't call apply with a record constructor:

(defrecord Foo. [id field])

(apply Foo. my-list)

fails at read time because it is not expecting Foo. in that place.

The only obvious workaround I could think of was to add a factory function:

(make-foo [id field] (Foo. id field))

which can be apply'ed of course.

Am I missing anything? I'd expect this from C#/Java but just thought it was a bit disappointing in Clojure...

agree it is a bit of an oddity, but personally it's never been a problem as I find the factory functions rather useful - this pattern supports more idiomatic Clojure usage, gives you more flexibility in pre-processing parameters, allows different sets of constructors for different purposes, provides a layer of abstraction etc. — mikera, Feb 17 '11 at 01:08

score 11 · Accepted Answer · answered Jan 21 '12 at 19:13

Circling back on this post-1.3....

In Clojure 1.3, defrecord creates two generated constructor functions. Given:

(defrecord Person [first last])

this will create a positional constructor function ->Person:

(->Person "alex" "miller")

and a map constructor function map->Person:

(map->Person {:first "string"})

Because this is a map, all keys are optional and take on a nil value in the constructed object.

You should require/use these functions from the ns where you declare the record, but you do not need to import the record class as you would when using the Java class constructor.

More details:

score 6 · Answer 2 · answered Feb 16 '11 at 13:51

6

Foo. is a Java class constructor so it has typical Java interop constraints with how you call it. Creating a constructor function is a common solution (it also means you don't have to import the Foo when in a different namespace).

answered Feb 16 '11 at 13:51

Alex Miller

69,183
25
122
167

That is a Java class ctor should be an implementation detail? I viewed this was the "new" defstruct with better performance characteristics. – Kurt Schelfthout Feb 16 '11 at 14:29
I wish it was only an implementation detail but that's not (yet) the case. – Alex Miller Feb 16 '11 at 14:43
See my other answer for post-1.3. The Java class nature can largely be ignored now. – Alex Miller Jan 21 '12 at 19:14

score 3 · Answer 3 · edited Jan 21 '12 at 19:14

The problem is known and there is lots of talk about it on the Clojure mailing list. More support will probably be added in future Clojure versions.

For now you have to use your own functions or use https://github.com/david-mcneil/defrecord2 which supports some features like:

print in an eval'able form
provide clojure function as constructor
accept named parameters (maps) in constructor
participate in pre/post walk multi-method

Clojure record constructors not first class?

3 Answers3