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-boun...@r-forge.wu-wien.ac.at
[mailto:rcpp-devel-boun...@r-forge.wu-wien.ac.at] On Behalf Of Romain Francois
Sent: Tuesday, June 18, 2013 9:37 PM
To: rcpp-de...@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@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
_______________________________________________
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
