More flexible attributes

[romainfrancois]

It would be useful for packages to be able to extend attributes. Package foo could register a foo::bar attribute to do something about a function, a class, whatever ...

I have one use case in mind for this in dplyr where it would be nice to be able to register hybrid handlers as:

// [[dplyr::handler(hitchhiker)]]
Result* hitchhiker_handler( SEXP, const LazySubsets&, int ){
    return new Hitchhiker ;        
}

See the hybrid evaluation vignette for context.

[romainfrancois]

@jjallaire what would you think about factoring (part of) attributes in a standalone R package.

[jjallaire]

I think that's a reasonable idea, but it is going to make maintaining and
updating Rcpp on CRAN more complicated (i.e. might require more
synchronized releases like the recent Rcpp & RcppArmadillo one).

Is there another way to allow Rcpp to use attributes in it's implementation
such as arranging for Makevars to call an R script to pre-process source
files? If so that might be the best of both worlds.

On Sat, Nov 9, 2013 at 2:15 AM, Romain François notifications@github.zcwsr.comwrote:

@jjallaire https://github.com/jjallaire what would you think about
factoring (part of) attributes in a standalone R package.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-28121747
.

[romainfrancois]

chicken and the egg problem, if attributes are in Rcpp and we need attributes to build Rcpp, then we need Rcpp to build Rcpp ...

[jjallaire]

I'm thinking that you might have an R script within the package that could
be sourced and invoked by Makevars. i.e. you could have an R code
dependency but not a package dependency on the attributes implementation.

That might be impossible or undesirable for many reasons I'm not
considering though.

On Sun, Nov 10, 2013 at 8:41 AM, Romain François
notifications@github.zcwsr.comwrote:

chicken and the egg problem, if attributes are in Rcpp and we need
attributes to build Rcpp, then we need Rcpp to build Rcpp ...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-28150768
.

[romainfrancois]

Working on this separately on the https://github.com/RcppCore/attributes repo.

[jjallaire]

I'm wondering if factoring attributes into their own package will force users of Rcpp to do this:

LinkingTo: Rcpp, attributes

Is that correct? If so I think that's an unfortunate side effect of splitting them out. I continue to think that if there is a way to keep the code inside Rcpp but still achieve the extensibility and Rcpp build enhancements you are seeking that would be best.

[romainfrancois]

Not sure we would need to add attributes to LinkingTo. I certainly would not like that either.

One of the reason I'd like attributes to be apart is that the Rcpp package is no longer the only Rcpp implementation. It would be nice to be able to benefit from changes in attributes from either Rcpp or Rcpp11, and perhaps Rcpp98

[jjallaire]

I am less concerned about this now that I understand that libRcpp.so is
still around (I had previously thought that LinkingTo would imply a
build-time only dependency and that the user might need an extra Depends or
LinkingTo to pull in the attributes package explicitly).

On Fri, Nov 15, 2013 at 4:10 PM, Romain François
notifications@github.zcwsr.comwrote:

Not sure we would need to add attributes to LinkingTo. I certainly would
not like that either.

One of the reason I'd like attributes to be apart is that the Rcpppackage is no longer the only
Rcpp implementation. It would be nice to be able to benefit from changes
in attributes from either Rcpp or Rcpp11, and perhaps Rcpp98

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-28603582
.

[romainfrancois]

I'm moving this to the next milestone. I think the "header mostly" feature on its own is enough material for a new release.

[coatless]

I think this issue can be closed out of the Rcpp tracker as the project has taken root over at Rcpp11/attributes.

Please close. (Tagging #506)