...
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.