Error formatting macro: pagetree: java.lang.NullPointerException
Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

rh says:

Please don't work on any other aspect of this until the problem section is good.


  • completeness and consistency: need to be able to read and write records like other Clojure types
    • better - it's a problem that moving from maps to records compromises read/print
  • dynamism: need to create defrecords without class-in-hand. Performantly, of course
    • rh - this smells like a desire, not a real problem for people
      • thus, low priority unless it falls out of something else
  • convenience: want map-like construction instead of positional slotwise construction
    • but why do we want map-like construction?
      • what are the problems with positional construction?
      • can they only be solved by map-like construction?
  • People often, but not always, write their own factory fns
    • not being standardized means people don't know what to expect
    • why are they doing that?
      • survey cases
        • optional fields
        • derived/private fields
        • factory fn gets pulled in from ns while class doesn't

Some history:

The record multimethod was almost ready to go when Rich raised the GC issue. What happens when somebody creates a ton of record classes over time? GC can collect records that are not longer in use, but doesn't clean up the old multimethod functions.

Open Issues

  • print/read syntax
    • record factory function needs to enable print/read syntax for defrecords
    • for now, use #=(record ...) per Rich
      • rh - that was 'for then', we should do better now
    • caveat: forces people to allow arbitrary execution in order to deserialize records
    • is there some way to open record instantiation without opening arbitrary execution?
      • e.g. special reader syntax for records?
      • rh - I'm open to that as part of a complete design in this area
  • GC friendliness
    • original proposed multimethod approach is a poor fit
      • would need some way to atomically remove old multimethod fns
      • and need to use two weak references (to class and to factory fn)
      • if you already need a weak map, and multimethods are in play just to map names -> factory fns, might as well skip multimethods and have just a weak map
    • record factory fn maintains map keyed by weak ref to class, value weak ref to class-specific factory fn
    • updates to factory fn also purge dead entries from the map (a la Clojure keywords)
  • what about deftypes?
    • first guess: you are on your own

Additional Reading

Some (non-contributed) code that demonstrates people's need for this: