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. _______________________________________________ Roxygen-devel mailing list Roxygen-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/roxygen-devel
