[Rcpp-devel] macros RCPP_FUNCTION_...,

[Romain Francois]

Sure. That is essentially what Dirk proposed. That is fine.

What I've done is add this section in our NEWS file:

     \item Deprecation plans:
     \itemize{
       \item The set of macros \code{RCPP_FUNCTION_} etc ... from the
       \code{preprocessor_generated.h} file will be deprecated in the 
next version
       of \code{Rcpp}, i.e they willl still be available but will 
generate some
       warning in addition to their expected behavior.
       In release +2 the macros will be removed
       from \code{Rcpp}. Users of these macros (if any) should start 
replacing them
       with more up to date code, such as using attributes or modules.
     }


So:
- when we release Rcpp 0.10.4 nothing changes. people can still enjoy 
using this feature, if anyone is.
- when we release Rcpp 0.10.5 the feature is still there, but with extra 
annoying warnings
- when we release Rcpp 0.10.6 the feature is gone.

Considering we release now approximately quarterly, this leaves a period 
between 6 and 9 months before the feature is gone.

I hope everybody will be ok with that. This is more work, and I actually 
need to remember to do it, but that is a good compromise.

Romain


Le 19/06/13 14:35, Smith, Dale (Norcross) a écrit :
> 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
>


-- 
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/13SrjxO : highlight 0.4.2
`- http://bit.ly/10X94UM : Mobile version of the graph gallery