Ideas
...
defrecord and deftype improvements for Clojure 1.3
Motivation
The Java unification of records prevents them from being first class, in either the data or fn sense:
- record data is not first class
- can't read/write them
- crummy choice: maps are good as data, need records for protocol polymorphism
- user code cannot fix this
- anything that requires EvalRead is not a fix
- can't read/write them
- record creation is not first class
- no per-record factory fn (or access to any associated fn plumbing, e.g. apply)
- Clojure level use/require doesn't get you access to records
- user code can mostly fix this (defrecord+factory macro)
- Symmetrically, PO Java classes are also not first class
- A unified literal interface reader form would be ideal
- Reduced import complexities
...
Solutions
For the sake of discussion, focus will revolve around example defrecords and deftypes defined as
...
Semantics of records as first class data
The semantics of record literals reader forms and record factory functions are defined as follows:
...
The <initialization value> refers to the same default default values for Java primitive types (as defined by type hinting on the record fields) or nil for instances. For record literalsreader forms, the keys and values must remain as constants as the literal their semantics require that the readable form coincide with the evalable form.
Record
...
and Type reader forms
There would be two additional reader forms added to Clojure.
Labelled record
...
reader form
| No Format |
|---|
#myns.MyRecord{:a 1, :b 2}
|
...
This syntax satisfies the need for a general-purpose Java class construction reader form. However, not all Java classes are considered fully constructed after the use of their constructors. Therefore, serialization support is not provided for any Java classes by default. For instances such as these, Clojure will continue to provide facilities via print-dup in the known ways.
...