[Roxygen-devel] roxygen3

[Peter Danenberg]

Quoth Hadley Wickham on Prickle-Prickle, the 27th of The Aftermath:
> Currently the roxygen2 code is hard to extend - the idea of roclets
> was good, but I think they were too big - you want to be able to
> work at the tag level so it's easier to add new features.

I've been thinking a little bit about this, and it would be nice if
the roclet (viz. roccer) model resembled roxygen1 in the sense that it
were based on function-composition.

I did a live-coding demo at LARUG where I showed the audience how to
create a custom roclet; and all the coding-by-convention stuff (e.g.
remembering to write roc_process and roc_output) was a little painful.

The original idea was to chain a series of roclets together that
optionally (and perhaps non-destructively) altered the parse-tree in
some specified order; possibly doing I/O.

This enabled the creation of e.g. translation roclets that would alter
the description associated with srcrefs for later processing; to
accomodate which in roxygen2, I had to do awful things like assigning
to the parent frame:

  https://github.com/klutometis/larug-roxygen/blob/master/translation-roclet.R

It was painfully laborious compared to the mapping/composition model.

Anyway, you may have solidified the architecture at this point; food
for thought, though.