Open romainfrancois opened 10 years ago
Thinking out loud, compileAttributes
and sourceCpp
each offer their own interpretation of a set of attributes (// [[Rcpp::export]]
, // [[Rcpp::depends]]
, // [[Rcpp::interfaces]]
). Perhaps, rather than tying each attribute to a function, we should define handlers for (groups of) attributes.
Users could register their own handlers for attributes of a certain form. So, they write a function like:
fooHandler <- handler( list("foo"), function(attributes) {
...
})
For packages, that handler could be called by another function (probably compileAttributes
), and would ensure that all attributes called foo
are passed in to that function. Then, R code defined is run to process those attributes in some fashion. Perhaps the handlers would all be defined in an attributes.R
file or something like that. This would also allow users to reuse, or extend, attributes to some extent, by adding in their own handlers for the same attributes.
I think package developers will still want all processing of attributes wrapped into a compileAttributes()
call; this call will have to:
.c
/ .cpp
files,Just some ideas.
What if we were to leverage the R package some more, i.e. sourceCpp were to create a temp package and load it.
The advantage of that is that sourceCpp
can then just call compileAttributes
and so we only have to implement compileAttributes
. This way handlers are handed e.g. the root directory of the package and the attribute.
This makes compileAttributes the work horse, then sourceCpp
can:
compileAttributes
to generate additional code and content (e.g. in the NAMESPACE, DESCRIPTION, ...) I think this is the way to go. @kevinushey ?
This sounds like a great idea. This could also provide a mechanism for users to have their compiled sourceCpp
code persist across sessions (e.g. by specifying the library by hand). I could imagine some users making 'ad-hoc' libraries of sourceCpp
ed code when prototyping and such.
One problem is that this sort of has to go through R CMD INSTALL
which is kind of slow. One alternative could be to use devtools::load_all
but this will use Rcpp to compile the attributes and this is not controllable. Perhaps I can later negociate something with hadley.
Believe it or not devtools::load_all
actually calls R CMD INSTALL
so it wouldn't be any faster.
One issue related to this approach is that it would break some existing sourceCpp
code. This is because sourceCpp
works by appending the generated code to the source file (thus picking up all typedefs and includes) whereas compileAttributes
works in a fresh source file (no typedefs, includes only as directed by inline plugins, etc.).
Thanks for the clarification. Must admit I did not go deep into load_all
code.
And that's a very good point. Perhaps this means back on the original idea of having different behavior for the same attribute depending on whether we do sourceCpp or compileAttributes.
Do we need some sort of context concept, i.e. a context gives a particular meaning to an attribute.
The obvious example is that
Rcpp::export
does not trigger the same things when sourceCpp'ing a single file or contributing to compileAttribute'ing a set of files in a package.So perhaps we could have a
sourceCpp
andcompileAttributes
contexts, or perhapsfile
andpackage
.