Error formatting macro: pagetree: java.lang.NullPointerException

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Note, this list is primarily RH's notes on Stu's patch. Stu's initial replies inline

  • hrm, the predicate language in describe thinking about this** always and/every?
      • single pred would allow arbitrary logic
    • Explore query-by-example, i.e. user provides partial data in same shape as returned
  • reflect-impl bad name for fn
    • prefer things like do-reflect, still a verb
    • I hate overloading "do" because it already means "force". Come to think about it, it's too bad doall isn't force-all. :-)
    • understand the problems with -impl, don't have a better word yet
  • typeref->name - typename ok
  • typeref->sym - typesym ok** typeref->* implies things of type typeref, we don't want to reify protocol like that
    • ditto - typepath
  • are we exposing the descriptor, internal-name confusion by having these helpers public, with no better docs than we complain about?
    • the easiest way to explain these is be enumerating a few examples (which the tests do)
    • this is a place where I want the tests inline (which doesn't work with our CI harness) or a well-known convention of looking to the tests for examples (like Ioke does)
    • if I am forced to repeat myself in tests and documentation I will just make these private to avoid having to answer the bigger questions. :-)
  • defrecord Constructor/Method/Field
    • make sure distinguishing these by type adds value only value is in reflection-specific pprint. Still undecided, let's discuss.
    • much pain today in writing generic reflection code due to unequal treatment of members
      • i.e. ctors are glorified static methods
    • I'd prefer a first cut with maps and see where that is inadequate
      • perhaps already done, notes?
  • defrecord JavaReflector/AsmReflector ok** unlike Contrstructor/Method/Field, these are plainly not information but are programming constructs and should be deftypes
  • describe's built in pprint
    • can we not get pprint to print the data structures nicely? I don't want to (see my design notes above). What I really thought I wanted was context-specific pprint.
    • giving the user a bunch of printout they can't lift and use as data isn't that great
      • may be more useful to enhance pprint
      • the thing that I don't like about existing pprint in this scenario is the verbosity of enumerating keys that are obvious from context. I don't have a solution.