[Rcpp-devel] macros RCPP_FUNCTION_...,

[Smith, Dale (Norcross)]

Hi all,

I've been reading this with some interest. I suggest:

* Announce an api change via Stack Overflow, blog, list, etc and put the announcement into the NEWS for the next release.
* Announce an effective date on the change and outline the reasons.

I think this should satisfy everyone and give users fair warning that a change is coming that may break their code.

Dale Smith, Ph.D.
Senior Financial Quantitative Analyst
Risk & Compliance
Fiserv
Office: 678-375-5315
www.fiserv.com

-----Original Message-----
From: rcpp-devel-bounces at r-forge.wu-wien.ac.at [mailto:rcpp-devel-bounces at r-forge.wu-wien.ac.at] On Behalf Of Romain Francois
Sent: Tuesday, June 18, 2013 9:37 PM
To: rcpp-devel at r-forge.wu-wien.ac.at
Subject: Re: [Rcpp-devel] macros RCPP_FUNCTION_...,

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 at lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel