Le 19/06/13 02:33, Darren Cook a écrit :
This is an opportunity for a quick diet. Just before the summer.

Looking good in a bikini is always important. :-)

glad you enjoyed the visual

That no-one uses it in any CRAN package is also compelling. (I just
searched on StackOverflow and no mention there either.)

Dirk wrote:
APIs are contracts we have with users.  I would prefer to see strong
reasons for change, rather than a style preference.

Romain wrote:
If we keep it we surely need to document it as part of this contract

I think this is the most compelling reason. It seems almost undocumented.

https://www.google.co.jp/search?q="RCPP_FUNCTION";
https://www.google.co.jp/search?q="RCPP_FUNCTION_0";

There is something here:
  http://dirk.eddelbuettel.com/blog/2010/05/17/

(BTW, shouldn't "RCPP_FUNCTION_VOID_2" have been "RCPP_FUNCTION_VOID_1" ?)

yes. so the single very well hidden bit of documentation we have about this is wrong.

Can those examples be mechanically converted to use Rcpp modules,
Romain?

I'm not writing mechanics for something that is never going to be used.

What do you want to see:

- this:

RCPP_FUNCTION_2( int, foobar, int x, int y){
            return x + y ;
          }

or this:

// [[Rcpp::export]]
int foobar( int x, int y){
    return x + y ;
}

The attributes feature is awesome. Anyone who reads c++ can understand what goes on. Not the same story with the macro.

I know their value, I wrote the code. I know what they are for. But we don't need them anymore.

If so, documenting how to convert might be sufficient, and
anyone who gets hit by the removal can spend 20 minutes updating their
code to work.

Darren

Yes. And I'm happy to so it for every single one of them. Of course, I'm not taking a big risk because nobody uses this.

If we leave the code as it is, the hypothetical user that does not exist is happy.

If we remove it, the same hypothetical user is first going to get upset, and then he will be happy to have better code when I have fixed it.

For everyone else, they are going to have an Rcpp with less clutter and a better ratio of [stuff that is in the package] / [stuff that is documented].


This in my view is positive. Of course eventually I don't care all that much. This was just a random idea.

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

R Graph Gallery: http://gallery.r-enthusiasts.com

blog:            http://blog.r-enthusiasts.com
|- http://bit.ly/Zs97qg  : highlight 0.4.1
`- http://bit.ly/10X94UM : Mobile version of the graph gallery

_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Reply via email to