Re: [Rd] legitimate use of :::
On Wed, May 14, 2014 at 12:29 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
On 13/05/2014 12:14 PM, Knut Krueger wrote:
Is there another new solution for this issue?
especially I would like to use:
utils:::.win32consoleCompletion
the use of this is suggested in the completion.r file of utils:
## test some typical completion attempts
library(utils)
testLine - function(line, cursor = nchar(line))
{
str(utils:::.win32consoleCompletion(line, cursor))
}
testLine()
I think you are misunderstanding the comments in that file. It's an
internal set of tests for the package, so test some typical completion
attempts is a description of the tests that follow, it's not a suggestion
that you should be able to run those lines
from your package.
If you do want access to the completion mechanism from a package, you should
write to its author (Deepayan Sarkar) and explain the kinds of things you
need to do. If you can convince him that giving you access is worth the
trouble of exposing some of it to user-level code, then he'll export a
function for you. (I think it's unlikely to be .win32consoleCompletion, but
who knows.)
Yes, .win32consoleCompletion() was meant for use by the Windows GUI,
but I can see a use-case for something similar elsewhere (for example,
ESS defines something analogous).
But I don't immediately see why another R package should need this. If
you have a legitimate use, we can discuss off-list and come up with a
solution.
-Deepayan
Duncan Murdoch
(full quote because of the age of the tread)
Kind regards Knut
Am 22.08.2013 20:57, schrieb Michael Friendly:
On 8/22/2013 7:45 AM, Uwe Ligges wrote:
On 22.08.2013 07:45, Yihui Xie wrote:
Hi,
So now R CMD check starts to warn against :::, but I believe sometimes
it is legitimate to use it when developing R packages. For example, I
have some utils functions that are not exported but I want to share
them across the packages that I maintain. I do not need to coordinate
with other authors about these internal functions since I'm the only
author and I know clearly what I'm doing, and I want to avoid copying
and pasting the code across packages just to avoid the NOTE in R CMD
check. What should I do in this case?
Nothing. The way you describe above seems to be a reasonable usage, iff
you are the same maintainer who knows what is going on. Other
maintainers should not use one of your not exported (hence non API)
functions, of course.
Uwe Ligges
Related to this is the use of other-package unexported utility functions
that don't pass Uwe's iff test, but I, as maintainer,
want to use in my package.
Cases in point: in heplots, I had used stats:::Pillai, stats:::Wilks,
stats:::Roy and stats:::LH for calculation in one of my functions.
Similarly, I had a need to use car:::df.terms, also unexported, but
don't want to ask John Fox to export it just for my use. Uwe's
reply suggests that I should not be using car:::df.terms, however.
To avoid the NOTEs (which often triggers a 'pls fix' upon submission to
CRAN), I simply copied/pasted these functions to my package, but this
seems wasteful.
-Michael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Am 14.05.2014 08:56, schrieb Deepayan Sarkar: On Wed, May 14, 2014 at 12:29 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: I think you are misunderstanding the comments in that file. It's an internal set of tests for the package, so test some typical completion attempts is a description of the tests that follow, it's not a suggestion that you should be able to run those lines from your package. If you do want access to the completion mechanism from a package, you should write to its author (Deepayan Sarkar) and explain the kinds of things you need to do. If you can convince him that giving you access is worth the trouble of exposing some of it to user-level code, then he'll export a function for you. (I think it's unlikely to be .win32consoleCompletion, but who knows.) Yes, .win32consoleCompletion() was meant for use by the Windows GUI, but I can see a use-case for something similar elsewhere (for example, ESS defines something analogous). But I don't immediately see why another R package should need this. If you have a legitimate use, we can discuss off-list and come up with a solution. As TinnR was used at the University I tried to update the TinnR package because it was removed from cran http://cran.rstudio.com/web/packages/TinnR/index.html I think they used the win32consoleCompletion to connect Tinnr (Windows) with R - I do not really know the reason. Actually I found that R-Studio is much better for R-beginner and available for all platforms. Thanks for your hints - but I will not solve this problem anymore Knut __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Is there another new solution for this issue?
especially I would like to use:
utils:::.win32consoleCompletion
the use of this is suggested in the completion.r file of utils:
## test some typical completion attempts
library(utils)
testLine - function(line, cursor = nchar(line))
{
str(utils:::.win32consoleCompletion(line, cursor))
}
testLine()
(full quote because of the age of the tread)
Kind regards Knut
Am 22.08.2013 20:57, schrieb Michael Friendly:
On 8/22/2013 7:45 AM, Uwe Ligges wrote:
On 22.08.2013 07:45, Yihui Xie wrote:
Hi,
So now R CMD check starts to warn against :::, but I believe sometimes
it is legitimate to use it when developing R packages. For example, I
have some utils functions that are not exported but I want to share
them across the packages that I maintain. I do not need to coordinate
with other authors about these internal functions since I'm the only
author and I know clearly what I'm doing, and I want to avoid copying
and pasting the code across packages just to avoid the NOTE in R CMD
check. What should I do in this case?
Nothing. The way you describe above seems to be a reasonable usage, iff
you are the same maintainer who knows what is going on. Other
maintainers should not use one of your not exported (hence non API)
functions, of course.
Uwe Ligges
Related to this is the use of other-package unexported utility functions
that don't pass Uwe's iff test, but I, as maintainer,
want to use in my package.
Cases in point: in heplots, I had used stats:::Pillai, stats:::Wilks,
stats:::Roy and stats:::LH for calculation in one of my functions.
Similarly, I had a need to use car:::df.terms, also unexported, but
don't want to ask John Fox to export it just for my use. Uwe's
reply suggests that I should not be using car:::df.terms, however.
To avoid the NOTEs (which often triggers a 'pls fix' upon submission to
CRAN), I simply copied/pasted these functions to my package, but this
seems wasteful.
-Michael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Tue, May 13, 2014 at 9:14 AM, Knut Krueger r...@knut-krueger.de wrote: Is there another new solution for this issue? especially I would like to use: utils:::.win32consoleCompletion the use of this is suggested in the completion.r file of utils: Besides forking the function (i.e. copy-and-paste it) if you think the function provides useful functionality you can try to persuade the maintainer to export it (and hence agree to support the function API for the foreseeable future) or even contribute the function to another more appropriate package (maybe even creating a new package in the process). - Trevor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 13/05/2014 12:14 PM, Knut Krueger wrote:
Is there another new solution for this issue?
especially I would like to use:
utils:::.win32consoleCompletion
the use of this is suggested in the completion.r file of utils:
## test some typical completion attempts
library(utils)
testLine - function(line, cursor = nchar(line))
{
str(utils:::.win32consoleCompletion(line, cursor))
}
testLine()
I think you are misunderstanding the comments in that file. It's an
internal set of tests for the package, so test some typical completion
attempts is a description of the tests that follow, it's not a
suggestion that you should be able to run those lines
from your package.
If you do want access to the completion mechanism from a package, you
should write to its author (Deepayan Sarkar) and explain the kinds of
things you need to do. If you can convince him that giving you access
is worth the trouble of exposing some of it to user-level code, then
he'll export a function for you. (I think it's unlikely to be
.win32consoleCompletion, but who knows.)
Duncan Murdoch
(full quote because of the age of the tread)
Kind regards Knut
Am 22.08.2013 20:57, schrieb Michael Friendly:
On 8/22/2013 7:45 AM, Uwe Ligges wrote:
On 22.08.2013 07:45, Yihui Xie wrote:
Hi,
So now R CMD check starts to warn against :::, but I believe sometimes
it is legitimate to use it when developing R packages. For example, I
have some utils functions that are not exported but I want to share
them across the packages that I maintain. I do not need to coordinate
with other authors about these internal functions since I'm the only
author and I know clearly what I'm doing, and I want to avoid copying
and pasting the code across packages just to avoid the NOTE in R CMD
check. What should I do in this case?
Nothing. The way you describe above seems to be a reasonable usage, iff
you are the same maintainer who knows what is going on. Other
maintainers should not use one of your not exported (hence non API)
functions, of course.
Uwe Ligges
Related to this is the use of other-package unexported utility functions
that don't pass Uwe's iff test, but I, as maintainer,
want to use in my package.
Cases in point: in heplots, I had used stats:::Pillai, stats:::Wilks,
stats:::Roy and stats:::LH for calculation in one of my functions.
Similarly, I had a need to use car:::df.terms, also unexported, but
don't want to ask John Fox to export it just for my use. Uwe's
reply suggests that I should not be using car:::df.terms, however.
To avoid the NOTEs (which often triggers a 'pls fix' upon submission to
CRAN), I simply copied/pasted these functions to my package, but this
seems wasteful.
-Michael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Yihui,
On Sun, Aug 25, 2013 at 7:53 PM, Yihui Xie x...@yihui.name wrote:
I know it is really bad, but the so-called good approach can be more
expensive than that snip
It is more expensive for you, yes. On the other hand, I'm pretty sure if
everyone were running around circumventing whatever CRAN tests they were
annoyed with at the time that situation would be enormously more expensive
for the R community as a whole.
For this particular case, I can imagine at least one case which can be
endless trouble to CRAN: if the package author A has talked to B to
use a hidden function in B's package, and B thinks that function is
relatively stable but does not want to export it; A may go ahead and
use it via :::. Both A and B understand that unexported function well,
then what should A do when submitting the package to CRAN? Should CRAN
continue adding rules for such exceptions?
IMO, what you are describing is a straightforward situation in which the
function should be exported. If a function is stable, the author is willing
to have other people depend on it, and other people want to use it and
would find it useful exporting it is the Right Way (tm) of doing that. What
is your argument that it should not be exported in this case?
To be clear I'm not arguing for outlawing :::, I DO think there are times
when it is better than the available alternatives, but I think the type of
selective exporting of functions just to the authors close friends that you
are describing is toxic to the ecosystem of R packages as a whole.
In other words, bad practices almost always have exceptions and edge
cases. Of course, the decision is always in CRAN's hands, and I will
try to respect and follow it as a package author.
The thing about bad practices is that yes, they have exceptions and edge
cases, but if the practice really is bad, most of the time someone thinks
they are in such an exception/edge case situation, they aren't. This is not
an attack on you or any individual person exhibiting bad practices, but
rather a descriptive statement about such things in general. Btw, this
applies well beyond coding. Go read James Joyce and then ask an english
professor if it's a good idea to write without any punctuation. They will
say no, and that any student who did so in their class will be heavily
penalized for it. And is that reasonable of them, even though things
written without punctuation can be hugely influential high art? I would
argue that it is.
My opinion on the matter is that the rules are important to follow, even if
they aren't quite optimal for any given situation. They aren't designed
for any specific situation, to do a pretty good job in the vast majority of
situations (and they are completely automated). To be honest I think there
is a good case for willfull circumvention of the checks such as you
describe being grounds for the package being ejected from CRAN, but its
easy for me to say that since I don't have any power. Regardless of the
reaction when it is detected (if ever, not sure how it ever would be, I'm
sure CRAN is entirely uninterested in an arms race), that type of thing is
bad behavior that is orders of magnitude worse than whatever the check was
put in place to prevent.
If a particular case really is an actual exception, I'm not convinced that
having to actually talk to a CRAN person and justify the NOTE is an
unreasonable price to be expected to pay.
Again, I'm not arguing for the outlawing of :::, in fact I have a patch to
R that implements the concept via NAMESPACE mechanics so you could have the
package in imports instead of depends and prevent cluttering the search
path when this is done. I don't think the situation your describing is a
great case for the use of ::: though, and certainly not one that is a good
case for CRAN allowing it, as I would imagine (without having any right to
speak for them) that CRAN's position is that all packages and authors
should be equal in terms of who gets to use what from whom. It is certainly
my position on the matter (not that many people care about such things :P)
~G
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA
On Fri, Aug 23, 2013 at 11:05 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
On 13-08-22 11:54 PM, Yihui Xie wrote:
Maybe it is not a good idea for R CMD check to check ::: at all, and a
warning in R-exts and ?':::' may well be enough. On the other hand, it
is just so easy to get around :::, because everybody can see its
source code:
It's a really bad idea to write tricky code to subvert the tests. If the
tests are wrong, you can argue for changes (and in this case you did, and
changes were made), but if you can't give a convincing argument, you
should
follow the good practices that the repository policies enforce.
Duncan Murdoch
`:::`
function (pkg, name)
{
pkg -
Re: [Rd] legitimate use of :::
Hi, related to this important discussion I have several questions: What can I do to explicitly state that I want to use a certain, *non-exported* generic function? The function I am currently talking of is predict.smooth.spline from package stats. As I want to make shure that *this* function is used I currently call stats:::predict.smooth.spline() in my code, which now triggers a NOTE on CRAN. Strange enough predict.smooth.spline even has a manual page but is not exported (as is true for many other generic functions as well). Is it advisable to specify (S3) methods without exporting them? How can I access exactly this function without using :::? And/or shouldn't we (R Core in this instance but others - including myself) export all methods (especially if a manual exists anyway)? A related question concerns the function stats:::n.knots. I want to use this function to compute the number of knots for a spline (not necessarily a smoothing spline as defined by smooth.spline were it is originally used). The source of the function even states as a comment: ## Namespace-hidden but at least available to programmeRs: So I guess this function can be considered to be stable and usable. Would it then be possible for R Core to export this function? Finally, if one needs to copy a function (perhaps with minor modifications), how does one properly state the authorship of the code that one copies? Are there any guidelines, rules, ...? Is it sufficient for small functions to state the original authorship as a comment in the source? Is it necessary to state the authorship in the manual? Or is it even required to state the quthorship in the DESCRITPION? I already did an extensive search of the R-devel mailing list but couldn't find an appropriate answer. And after all I do not want to spend hours and hours thinking about licenses, authorship etc. but I want to produce nice and usable code (but also want to mention the original authors appropriately)! Happy to learn more and read your thoughts and ideas about these issues. All the best, Benjamin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 26/08/2013 8:51 AM, Benjamin Hofner wrote: Hi, related to this important discussion I have several questions: What can I do to explicitly state that I want to use a certain, *non-exported* generic function? The function I am currently talking of is predict.smooth.spline from package stats. As I want to make shure that *this* function is used I currently call stats:::predict.smooth.spline() in my code, which now triggers a NOTE on CRAN. Strange enough predict.smooth.spline even has a manual page but is not exported (as is true for many other generic functions as well). Actually the standard name is that predict() is a generic function, predict.smooth.spline() is a method, but it's a good question. Can you describe why you want to call that method on something that isn't a smooth.spline object? Is it advisable to specify (S3) methods without exporting them? How can I access exactly this function without using :::? And/or shouldn't we (R Core in this instance but others - including myself) export all methods (especially if a manual exists anyway)? The general reason for hiding methods is that it allows the author of the package to change the internal implementation of the class without worrying that it will break code that uses the method, i.e. it will stop usages such as yours. So you need to explain why you are doing what you are doing. A related question concerns the function stats:::n.knots. I want to use this function to compute the number of knots for a spline (not necessarily a smoothing spline as defined by smooth.spline were it is originally used). The source of the function even states as a comment: ## Namespace-hidden but at least available to programmeRs: So I guess this function can be considered to be stable and usable. Would it then be possible for R Core to export this function? Finally, if one needs to copy a function (perhaps with minor modifications), how does one properly state the authorship of the code that one copies? Are there any guidelines, rules, ...? Is it sufficient for small functions to state the original authorship as a comment in the source? Is it necessary to state the authorship in the manual? Or is it even required to state the quthorship in the DESCRITPION? I already did an extensive search of the R-devel mailing list but couldn't find an appropriate answer. And after all I do not want to spend hours and hours thinking about licenses, authorship etc. but I want to produce nice and usable code (but also want to mention the original authors appropriately)! I would say that you should certainly state it in the man page, and have something in the DESCRIPTION file as well. It might be something like Author: Duncan Murdoch, with code from others (see the man pages) However, I just looked at rgl (a package I maintain), and I see we didn't do that. We have a separate README file listing other credits. Duncan Murdoch Happy to learn more and read your thoughts and ideas about these issues. All the best, Benjamin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Dear Duncan, thank you for the quick reply. Am 26.08.2013 16:47, schrieb Duncan Murdoch: On 26/08/2013 8:51 AM, Benjamin Hofner wrote: Hi, related to this important discussion I have several questions: What can I do to explicitly state that I want to use a certain, *non-exported* generic function? The function I am currently talking of is predict.smooth.spline from package stats. As I want to make shure that *this* function is used I currently call stats:::predict.smooth.spline() in my code, which now triggers a NOTE on CRAN. Strange enough predict.smooth.spline even has a manual page but is not exported (as is true for many other generic functions as well). Actually the standard name is that predict() is a generic function, predict.smooth.spline() is a method, but it's a good question. Can you describe why you want to call that method on something that isn't a smooth.spline object? Actually the object is a smooth.spline object but with additional attributes and more classes, i.e., class(mod) [1] opm_model smooth.spline_model smooth.spline Now I have a specialized predict function predict.smooth.spline_model which in turn calls predict.smooth.spline. I just tried to use NextMethod(generic = predict, object, ...) and it seems to work. So this seems to be the desired solution. I tried this earlier and got error messages, perhaps because I omitted the argument generic. I guess the function then was confused what the generic is (predict or predict.smooth). Is it advisable to specify (S3) methods without exporting them? How can I access exactly this function without using :::? And/or shouldn't we (R Core in this instance but others - including myself) export all methods (especially if a manual exists anyway)? The general reason for hiding methods is that it allows the author of the package to change the internal implementation of the class without worrying that it will break code that uses the method, i.e. it will stop usages such as yours. So you need to explain why you are doing what you are doing. I see no difference in these two ways to call the next generic function: In both cases I can (and do) specify further arguments, namely x for new data and deriv = 0. Thus in both cases I rely on the interface in the same way. I do not see any bonus for the package maintainer (both of the depending and dependent package). The interface stays the same and the class could change in both situations. Isn't a method always relying on the current implementation of a class? And isn't anything else more than unwanted? So again? Why hiding a method? The only reason I see is that one doesn't want to document the function properly. A related question concerns the function stats:::n.knots. I want to use this function to compute the number of knots for a spline (not necessarily a smoothing spline as defined by smooth.spline were it is originally used). The source of the function even states as a comment: ## Namespace-hidden but at least available to programmeRs: So I guess this function can be considered to be stable and usable. Would it then be possible for R Core to export this function? Do I need to file a formal request for this issue? Finally, if one needs to copy a function (perhaps with minor modifications), how does one properly state the authorship of the code that one copies? Are there any guidelines, rules, ...? Is it sufficient for small functions to state the original authorship as a comment in the source? Is it necessary to state the authorship in the manual? Or is it even required to state the quthorship in the DESCRITPION? I already did an extensive search of the R-devel mailing list but couldn't find an appropriate answer. And after all I do not want to spend hours and hours thinking about licenses, authorship etc. but I want to produce nice and usable code (but also want to mention the original authors appropriately)! I would say that you should certainly state it in the man page, and have something in the DESCRIPTION file as well. It might be something like Author: Duncan Murdoch, with code from others (see the man pages) However, I just looked at rgl (a package I maintain), and I see we didn't do that. We have a separate README file listing other credits. This is a good solution. Do I need to specify the original License etc? And what about a helper function such as stats:::n.knots? This will not appear in the manual of my package. Is it sufficient in this case to document the authorship in the source (and perhaps a README as you suggested)? Duncan Murdoch Happy to learn more and read your thoughts and ideas about these issues. All the best, Benjamin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Benjamin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
I would say that you should certainly state it in the man page, and have something in the DESCRIPTION file as well. It might be something like Author: Duncan Murdoch, with code from others (see the man pages) However, I just looked at rgl (a package I maintain), and I see we didn't do that. We have a separate README file listing other credits. The feedback that I've been getting from CRAN maintainers lately is that you have to include all source code contributors in the authors field. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
It seems that several people in this thread assumes that it is easy or even possible to convince an author of a package to export a given function. This is clearly not always true, partly because as an author you gain additional work by doing this. The downsides to using ::: is really about the possibility of the package breaking or misfunctioning, and I don't really see why this is anyone else's problem. Best, Kasper On Mon, Aug 26, 2013 at 11:38 AM, Hadley Wickham h.wick...@gmail.comwrote: I would say that you should certainly state it in the man page, and have something in the DESCRIPTION file as well. It might be something like Author: Duncan Murdoch, with code from others (see the man pages) However, I just looked at rgl (a package I maintain), and I see we didn't do that. We have a separate README file listing other credits. The feedback that I've been getting from CRAN maintainers lately is that you have to include all source code contributors in the authors field. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
This is a good solution. Do I need to specify the original License etc? And what about a helper function such as stats:::n.knots? This will not appear in the manual of my package. Is it sufficient in this case to document the authorship in the source (and perhaps a README as you suggested)? If the license is the same as your projects you just need the proper copyright notice. As Hadley suggests it is a good idea to also document the appropriate authorship in the Authors field in the DESCRIPTION as well. If the license is different but permissive than then it typically doesn't need go into DESCRIPTION or a separate LICENSE file but the permissive license text does usually need to either go into inst/COPYRIGHT or at the top of the relevant code file: https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html https://www.softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html If the license is more restrictive you must either convert your project or not use the code at all although for very small code snippets you might have fair use rights (at least in the United States). - Trevor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Mon, Aug 26, 2013 at 1:06 PM, Trevor Davis trevor.l.da...@gmail.com wrote: This is a good solution. Do I need to specify the original License etc? And what about a helper function such as stats:::n.knots? This will not appear in the manual of my package. Is it sufficient in this case to document the authorship in the source (and perhaps a README as you suggested)? If the license is the same as your projects you just need the proper copyright notice. As Hadley suggests it is a good idea to also document the appropriate authorship in the Authors field in the DESCRIPTION as well. If the license is different but permissive than then it typically doesn't need go into DESCRIPTION or a separate LICENSE file but the permissive license text does usually need to either go into inst/COPYRIGHT or at the top of the relevant code file: https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html https://www.softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html That may be true for other open source projects, but that is not the interpretation that cran maintainers have used in the past. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 26/08/2013 1:57 PM, Kasper Daniel Hansen wrote: It seems that several people in this thread assumes that it is easy or even possible to convince an author of a package to export a given function. This is clearly not always true, partly because as an author you gain additional work by doing this. The downsides to using ::: is really about the possibility of the package breaking or misfunctioning, and I don't really see why this is anyone else's problem. As long as you keep the package to yourself, it's nobody's problem but yours. If you want CRAN to distribute it, then it harms their reputation if it doesn't meet their standards. Duncan Murdoch Best, Kasper On Mon, Aug 26, 2013 at 11:38 AM, Hadley Wickham h.wick...@gmail.com mailto:h.wick...@gmail.com wrote: I would say that you should certainly state it in the man page, and have something in the DESCRIPTION file as well. It might be something like Author: Duncan Murdoch, with code from others (see the man pages) However, I just looked at rgl (a package I maintain), and I see we didn't do that. We have a separate README file listing other credits. The feedback that I've been getting from CRAN maintainers lately is that you have to include all source code contributors in the authors field. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailto:R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 26/08/2013 11:20 AM, Benjamin Hofner wrote: Dear Duncan, thank you for the quick reply. Am 26.08.2013 16:47, schrieb Duncan Murdoch: On 26/08/2013 8:51 AM, Benjamin Hofner wrote: Hi, related to this important discussion I have several questions: What can I do to explicitly state that I want to use a certain, *non-exported* generic function? The function I am currently talking of is predict.smooth.spline from package stats. As I want to make shure that *this* function is used I currently call stats:::predict.smooth.spline() in my code, which now triggers a NOTE on CRAN. Strange enough predict.smooth.spline even has a manual page but is not exported (as is true for many other generic functions as well). Actually the standard name is that predict() is a generic function, predict.smooth.spline() is a method, but it's a good question. Can you describe why you want to call that method on something that isn't a smooth.spline object? Actually the object is a smooth.spline object but with additional attributes and more classes, i.e., class(mod) [1] opm_model smooth.spline_model smooth.spline Now I have a specialized predict function predict.smooth.spline_model which in turn calls predict.smooth.spline. I just tried to use NextMethod(generic = predict, object, ...) and it seems to work. So this seems to be the desired solution. I tried this earlier and got error messages, perhaps because I omitted the argument generic. I guess the function then was confused what the generic is (predict or predict.smooth). Is it advisable to specify (S3) methods without exporting them? How can I access exactly this function without using :::? And/or shouldn't we (R Core in this instance but others - including myself) export all methods (especially if a manual exists anyway)? The general reason for hiding methods is that it allows the author of the package to change the internal implementation of the class without worrying that it will break code that uses the method, i.e. it will stop usages such as yours. So you need to explain why you are doing what you are doing. I see no difference in these two ways to call the next generic function: In both cases I can (and do) specify further arguments, namely x for new data and deriv = 0. Thus in both cases I rely on the interface in the same way. I do not see any bonus for the package maintainer (both of the depending and dependent package). The interface stays the same and the class could change in both situations. Isn't a method always relying on the current implementation of a class? And isn't anything else more than unwanted? So again? Why hiding a method? The only reason I see is that one doesn't want to document the function properly. But as you've discovered, you don't need ::: access, you can use NextMethod. You would need ::: access if the object wasn't a smooth.spline object, because then the generic and NextMethod wouldn't dispatch to the method. If you were calling a smooth.spline method on something that is not a smooth.spline object, your code could break if something about the smooth.spline class was changed, and the predict method for it was adjusted to compensate. A related question concerns the function stats:::n.knots. I want to use this function to compute the number of knots for a spline (not necessarily a smoothing spline as defined by smooth.spline were it is originally used). The source of the function even states as a comment: ## Namespace-hidden but at least available to programmeRs: So I guess this function can be considered to be stable and usable. Would it then be possible for R Core to export this function? Do I need to file a formal request for this issue? It might be better to write to the author of that comment. You can find out who that is using svn blame (or as some of us prefer, svn praise) on the file. Finally, if one needs to copy a function (perhaps with minor modifications), how does one properly state the authorship of the code that one copies? Are there any guidelines, rules, ...? Is it sufficient for small functions to state the original authorship as a comment in the source? Is it necessary to state the authorship in the manual? Or is it even required to state the quthorship in the DESCRITPION? I already did an extensive search of the R-devel mailing list but couldn't find an appropriate answer. And after all I do not want to spend hours and hours thinking about licenses, authorship etc. but I want to produce nice and usable code (but also want to mention the original authors appropriately)! I would say that you should certainly state it in the man page, and have something in the DESCRIPTION file as well. It might be something like Author: Duncan Murdoch, with code from others (see the man pages) However, I just looked at rgl (a package I maintain), and I see we didn't do that. We have a separate README file listing other credits. This is a
Re: [Rd] legitimate use of :::
Am 26.08.2013 17:38, schrieb Hadley Wickham: I would say that you should certainly state it in the man page, and have something in the DESCRIPTION file as well. It might be something like Author: Duncan Murdoch, with code from others (see the man pages) However, I just looked at rgl (a package I maintain), and I see we didn't do that. We have a separate README file listing other credits. The feedback that I've been getting from CRAN maintainers lately is that you have to include all source code contributors in the authors field. Hadley I read these mails as well when I was looking for a good way to document code contributions. However, it seems to be nonsense to me, especially if you really just duplicate a simple function such as the n.knots. Next time I just rewrite the function (which doesn't seem to be good practice as well). Well, on the other hand it reads nice to have R Core as contributing authors in my package(s)... Perhaps a new field in DESCRIPTION and a standardized way how to name authors of functions one has duplicated would save a lot of the hassle? I could imagine a field that requires the structure: Contributions: function (pkg): Authors e.g. n.knots (stats): R Core (perhaps with an added LICENSE field) Benjamin -- ** Dr. rer. nat. Benjamin Hofner Institut für Medizininformatik, Biometrie und Epidemiologie Friedrich-Alexander-Universität Erlangen-Nürnberg Waldstr. 6 - 91054 Erlangen - Germany Tel: +49-9131-85-22707 Fax: +49-9131-85-25740 Office: Room 3.036 Universitätsstraße 22 (Entrance at the left side of the building) benjamin.hof...@fau.de http://www.imbe.med.uni-erlangen.de/cms/benjamin_hofner.html http://www.benjaminhofner.de __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Dear Duncan, -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- project.org] On Behalf Of Duncan Murdoch Sent: Monday, August 26, 2013 2:24 PM To: Benjamin Hofner Cc: r-devel@r-project.org Subject: Re: [Rd] legitimate use of ::: On 26/08/2013 11:20 AM, Benjamin Hofner wrote: Dear Duncan, thank you for the quick reply. Am 26.08.2013 16:47, schrieb Duncan Murdoch: On 26/08/2013 8:51 AM, Benjamin Hofner wrote: Hi, . . . This is a good solution. Do I need to specify the original License etc? And what about a helper function such as stats:::n.knots? This will not appear in the manual of my package. Is it sufficient in this case to document the authorship in the source (and perhaps a README as you suggested)? I think you want to give credit in a place where users will see it, not just in the source. Our README solution isn't good for that, because most people will never know they have that file. Duncan Murdoch I've been giving credit in the Authors@R: field of the DESCRIPTION file and via comments in the source code, but this isn't a good solution since the first is non-specific and the second won't be read by users. Now that this practice will be much more frequent as a consequence of eliminating ::: references, it would be nice to have a standard solution. Maybe using the comment argument to person() in the Authors@R field makes sense; I haven't tried this. Best, John __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Sat, Aug 24, 2013 at 9:46 AM, Kasper Daniel Hansen kasperdanielhan...@gmail.com wrote: On Thu, Aug 22, 2013 at 8:27 PM, Peter Meilstrup Using ::: on a package you don't control can be more dangerous. For a package author to choose to export a function to the public interface represents at least some assurance that that interface will be stable or slow-moving. But there are no implied assurances about how code in the private namespace might change behind the scenes. I might completely refactor the code and change the behavior of any private function between 0.0.1 releases, but I would not do that for exported functions. This is true (that it could be dangerous), but sometimes, as a package author, I am willing to take this risk. Personally, I don't do this lightly, but sometimes there is no way around it, particular if the hidden function does some magic in its own NAMESPACE. It is not all functions that one can just easily copy over into you own package. It is fine to say that the use of ::: should be discouraged, it is another thing if it prevents you from submitting to CRAN (which I don't know for sure; I thought that Notes were ok?). Closely related and particularly on which NOTEs are CRAN show stoppers and which are not: I find 'R CMD check' extremely useful and I believe it has greatly improved the quality of R and contributed packages including mine. The more checks/tests the better. No doubt about that. Keeping in mind the famous statement that R is not CRAN (or is it CRAN is not R), and knowing there is great overlap between R core and CRAN team members, it is still not easy to distinguish between what is R and what is CRAN and where they're heading. The CRAN Repository Policy [http://cran.r-project.org/web/packages/policies.html ; very useful addition] is very clear on 'R CMD check --as-cran' WARNINGs and ERRORs, but for NOTEs it leaves room for interpretation. For instance, it mentions that package with significant notes needs to be updated, but from experience I'd say it's up to the package developer to guess what CRAN means by significant notes. It also gives sends the message that there is some leeway for the developer to publish a package with (regular?) NOTEs as long as s/he has considered their implications [cf. If there are warnings or notes you cannot eliminate (for example because you believe them to be spurious) send an explanatory note as part of your covering email, or as a comment on the submission form.]. Unfortunately you won't find out until submission, which seems a waste of time for both the developer and CRAN. If CRAN accept certain 'R CMD check --as-cran' NOTEs but not others, may I propose some kind of mechanism to '--as-cran' that grep()/grep(invert=TRUE) which NOTEs are significant/non-significant for CRAN submissions/updates? That may be too much work to be exhaustive, but at least the ones that, to CRAN, are obviously rejected/accepted would be helpful. With 4700+ packages of CRAN with lots of daily submissions/updates, the CRAN team has a much better idea what's accepted or not, than each individual developer. If it is the case that CRAN consider the majority of the NOTEs to be significant, I propose to clarify/be explicit about that in the CRAN Repository Policy document. ...and finally, thanks to the CRAN team [if they read this] for the work they put in daily. /Henrik PS. I am aware that proposals to CRAN should be sent to CRAN, but it's useful to have this discussion among R developers before going one-on-one with CRAN. If there is an agreement on the above, I'll send it off to the CRAN team. Best, Kasper [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 13-08-22 11:54 PM, Yihui Xie wrote:
Maybe it is not a good idea for R CMD check to check ::: at all, and a
warning in R-exts and ?':::' may well be enough. On the other hand, it
is just so easy to get around :::, because everybody can see its
source code:
It's a really bad idea to write tricky code to subvert the tests. If
the tests are wrong, you can argue for changes (and in this case you
did, and changes were made), but if you can't give a convincing
argument, you should follow the good practices that the repository
policies enforce.
Duncan Murdoch
`:::`
function (pkg, name)
{
pkg - as.character(substitute(pkg))
name - as.character(substitute(name))
get(name, envir = asNamespace(pkg), inherits = FALSE)
}
Then the package authors who really want to take the risk may start
another hide and seek game, e.g.
`%:::%` = function(pkg, fun) get(fun, envir = asNamespace(pkg),
inherits = FALSE)
'stats' %:::% 'Pillai'
Non-exported functions do not necessarily imply instability. Maybe it
is just because the author is too lazy to document them, or he/she did
not realize these functions happen to be useful for another author.
Although R-devel does not warn against ::: on the packages of the same
maintainer now, these maintainers may change in the future, or one
maintainer can be an author but not maintainer of another package,
from which he/she imports an unexported function, or package authors
have coordinated well with each other about the unexported functions.
I believe there are other legitimate reasons for :::, which might make
it difficult for R to cover all these cases, and also bring additional
communications between package authors and CRAN.
In conclusion, R CMD check cannot really stop :::, and ::: can be
there for good reasons, so how about just let it go?
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA
On Thu, Aug 22, 2013 at 9:02 PM, Gabriel Becker gmbec...@ucdavis.edu wrote:
Hey guys,
Because I was curious and had nothing else that I should have been doing
(that second part is a lie), I looked into the namespace code.
I have a working patch that implements importHiddenFrom. It doesn't
currently check whether you then export that symbol (which should not be
allowed) but that would be easy to implement.
Is there any desire from R-core to have add the importHiddenFrom
functionality? If so I can add the export check and submit the patch either
here or on bugzilla. I figure its a long shot but hey, at least I now know
how the namespace stuff works.
I do agree with Peter Meilstrup that poking around at the internals of
someone else's code is often not a good idea, but as others have pointed
out it is done in practice in some fairly high-profile packages, and if its
going to happen it seems like it would be nice to indicate as much in the
NAMESPACE file.
~G
On Thu, Aug 22, 2013 at 5:41 PM, Gray g...@clhn.co wrote:
Peter Meilstrup: (05:01PM on Thu, Aug 22)
One most often encounters namespace conflicts at the user level, when
loading two packages that have no logical connection other than both
bearing on your problem of the moment.
Unless I'm mistaken, you can reassign the hidden functions, ie
fna - joespackage:::usefulfunction
fnb - janespackage:::usefulfunction
which is a little bit of a pain, but makes the user's code
unambiguous. This also works with two colons for explicitly exported
functions.
--
Gray Calhoun, Assistant Professor of Economics at Iowa State
http://gray.clhn.co (web)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 13-08-24 12:46 PM, Kasper Daniel Hansen wrote: On Thu, Aug 22, 2013 at 8:27 PM, Peter Meilstrup Using ::: on a package you don't control can be more dangerous. For a package author to choose to export a function to the public interface represents at least some assurance that that interface will be stable or slow-moving. But there are no implied assurances about how code in the private namespace might change behind the scenes. I might completely refactor the code and change the behavior of any private function between 0.0.1 releases, but I would not do that for exported functions. This is true (that it could be dangerous), but sometimes, as a package author, I am willing to take this risk. Personally, I don't do this lightly, but sometimes there is no way around it, particular if the hidden function does some magic in its own NAMESPACE. It is not all functions that one can just easily copy over into you own package. It is fine to say that the use of ::: should be discouraged, it is another thing if it prevents you from submitting to CRAN (which I don't know for sure; I thought that Notes were ok?). CRAN is a good place to send your packages because it does some quality control on the packages it accepts. As I said in my message to Yihui, if you think the test is wrong, you can argue about that and it might be changed, but if you can't convince the CRAN maintainers of the validity of your point, you shouldn't send your package there. There are plenty of other places (github, R-forge, etc.) where you can distribute it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
I know it is really bad, but the so-called good approach can be more
expensive than that, primarily because a package with a NOTE in R CMD
check is likely to be rejected by CRAN, or authors have to justify the
NOTE in the email.
For this particular case, I can imagine at least one case which can be
endless trouble to CRAN: if the package author A has talked to B to
use a hidden function in B's package, and B thinks that function is
relatively stable but does not want to export it; A may go ahead and
use it via :::. Both A and B understand that unexported function well,
then what should A do when submitting the package to CRAN? Should CRAN
continue adding rules for such exceptions?
In other words, bad practices almost always have exceptions and edge
cases. Of course, the decision is always in CRAN's hands, and I will
try to respect and follow it as a package author.
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA
On Fri, Aug 23, 2013 at 11:05 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
On 13-08-22 11:54 PM, Yihui Xie wrote:
Maybe it is not a good idea for R CMD check to check ::: at all, and a
warning in R-exts and ?':::' may well be enough. On the other hand, it
is just so easy to get around :::, because everybody can see its
source code:
It's a really bad idea to write tricky code to subvert the tests. If the
tests are wrong, you can argue for changes (and in this case you did, and
changes were made), but if you can't give a convincing argument, you should
follow the good practices that the repository policies enforce.
Duncan Murdoch
`:::`
function (pkg, name)
{
pkg - as.character(substitute(pkg))
name - as.character(substitute(name))
get(name, envir = asNamespace(pkg), inherits = FALSE)
}
Then the package authors who really want to take the risk may start
another hide and seek game, e.g.
`%:::%` = function(pkg, fun) get(fun, envir = asNamespace(pkg),
inherits = FALSE)
'stats' %:::% 'Pillai'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Thu, Aug 22, 2013 at 8:27 PM, Peter Meilstrup Using ::: on a package you don't control can be more dangerous. For a package author to choose to export a function to the public interface represents at least some assurance that that interface will be stable or slow-moving. But there are no implied assurances about how code in the private namespace might change behind the scenes. I might completely refactor the code and change the behavior of any private function between 0.0.1 releases, but I would not do that for exported functions. This is true (that it could be dangerous), but sometimes, as a package author, I am willing to take this risk. Personally, I don't do this lightly, but sometimes there is no way around it, particular if the hidden function does some magic in its own NAMESPACE. It is not all functions that one can just easily copy over into you own package. It is fine to say that the use of ::: should be discouraged, it is another thing if it prevents you from submitting to CRAN (which I don't know for sure; I thought that Notes were ok?). Best, Kasper [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
To avoid the NOTEs (which often triggers a 'pls fix' upon submission to CRAN), I simply copied/pasted these functions to my package, but this seems wasteful. An issue is how one acknowledges the author of the cut and pasted code. Assume that for one reason or another the original function can't easily be made available via NAMESPACEs and so to avoid CRAN submission complaints you are forced into cut and copying. If the copied code is somewhat substantial a short acknowledgment on a man page is insufficient. As far as I know the only alternative to list the author of the copied code in the Author field of your DESCRIPTION file. This makes the Author field ungainly (especially if the copied-from package has itself a lengthy Author field) and gives disproportionate credit to the author of the copied code over those in Depends. It would be good if there was a better mechanism in the DESCRIPTION file for acknowledging authors you copied code from. Tricky, lots of grey areas. On balance I think I'm in the camp of those who say ::: should allowed. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 22.08.2013 07:45, Yihui Xie wrote: Hi, So now R CMD check starts to warn against :::, but I believe sometimes it is legitimate to use it when developing R packages. For example, I have some utils functions that are not exported but I want to share them across the packages that I maintain. I do not need to coordinate with other authors about these internal functions since I'm the only author and I know clearly what I'm doing, and I want to avoid copying and pasting the code across packages just to avoid the NOTE in R CMD check. What should I do in this case? Nothing. The way you describe above seems to be a reasonable usage, iff you are the same maintainer who knows what is going on. Other maintainers should not use one of your not exported (hence non API) functions, of course. Uwe Ligges Regards, Yihui -- Yihui Xie xieyi...@gmail.com Web: http://yihui.name Department of Statistics, Iowa State University 102 Snedecor Hall, Ames, IA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 8/22/2013 7:45 AM, Uwe Ligges wrote: On 22.08.2013 07:45, Yihui Xie wrote: Hi, So now R CMD check starts to warn against :::, but I believe sometimes it is legitimate to use it when developing R packages. For example, I have some utils functions that are not exported but I want to share them across the packages that I maintain. I do not need to coordinate with other authors about these internal functions since I'm the only author and I know clearly what I'm doing, and I want to avoid copying and pasting the code across packages just to avoid the NOTE in R CMD check. What should I do in this case? Nothing. The way you describe above seems to be a reasonable usage, iff you are the same maintainer who knows what is going on. Other maintainers should not use one of your not exported (hence non API) functions, of course. Uwe Ligges Related to this is the use of other-package unexported utility functions that don't pass Uwe's iff test, but I, as maintainer, want to use in my package. Cases in point: in heplots, I had used stats:::Pillai, stats:::Wilks, stats:::Roy and stats:::LH for calculation in one of my functions. Similarly, I had a need to use car:::df.terms, also unexported, but don't want to ask John Fox to export it just for my use. Uwe's reply suggests that I should not be using car:::df.terms, however. To avoid the NOTEs (which often triggers a 'pls fix' upon submission to CRAN), I simply copied/pasted these functions to my package, but this seems wasteful. -Michael -- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. Chair, Quantitative Methods York University Voice: 416 736-2100 x66249 Fax: 416 736-5814 4700 Keele StreetWeb: http://www.datavis.ca Toronto, ONT M3J 1P3 CANADA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Aug 22, 2013, at 20:57 , Michael Friendly wrote: Cases in point: in heplots, I had used stats:::Pillai, stats:::Wilks, stats:::Roy and stats:::LH for calculation in one of my functions. That particular case has been on what remains of my conscience for some time -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Dear Michael and Uwe, -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- project.org] On Behalf Of Michael Friendly Sent: Thursday, August 22, 2013 2:57 PM To: Uwe Ligges Cc: R-devel Subject: Re: [Rd] legitimate use of ::: On 8/22/2013 7:45 AM, Uwe Ligges wrote: On 22.08.2013 07:45, Yihui Xie wrote: Hi, So now R CMD check starts to warn against :::, but I believe sometimes it is legitimate to use it when developing R packages. For example, I have some utils functions that are not exported but I want to share them across the packages that I maintain. I do not need to coordinate with other authors about these internal functions since I'm the only author and I know clearly what I'm doing, and I want to avoid copying and pasting the code across packages just to avoid the NOTE in R CMD check. What should I do in this case? Nothing. The way you describe above seems to be a reasonable usage, iff you are the same maintainer who knows what is going on. Other maintainers should not use one of your not exported (hence non API) functions, of course. Uwe Ligges Related to this is the use of other-package unexported utility functions that don't pass Uwe's iff test, but I, as maintainer, want to use in my package. Cases in point: in heplots, I had used stats:::Pillai, stats:::Wilks, stats:::Roy and stats:::LH for calculation in one of my functions. Similarly, I had a need to use car:::df.terms, also unexported, but don't want to ask John Fox to export it just for my use. Uwe's reply suggests that I should not be using car:::df.terms, however. To avoid the NOTEs (which often triggers a 'pls fix' upon submission to CRAN), I simply copied/pasted these functions to my package, but this seems wasteful. I think that the ideal solution is for everyone to export functions that somewhat else might want, but it's hard to anticipate what these are, and it would be useful then to differentiate functions that are meant for end users from those meant for developers. Maybe packages could document the latter in something like a Utilities.Rd file. Probably there's a better, more formal, solution. The stats:::Pillai, Wilks, HL, and Roy functions seem reasonable candidates for export -- I too use these functions, in the car package, and have resorted to the fix that Michael adopted. I'd be happy to export df.terms, but would rather segregate it from end-user functions. It's also clear to me that enforcing namespace conventions more consistently, which is certainly desirable in the abstract, opens a can of worms, especially for the CRAN administrators. One hopes that we'll all survive the process and will have better packages in the end. My two cents. John -Michael -- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. Chair, Quantitative Methods York University Voice: 416 736-2100 x66249 Fax: 416 736-5814 4700 Keele StreetWeb: http://www.datavis.ca Toronto, ONT M3J 1P3 CANADA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
To avoid the NOTEs (which often triggers a 'pls fix' upon submission to CRAN), I simply copied/pasted these functions to my package, but this seems wasteful. Wasteful of disk space, but disk space is cheap. It's less wasteful of your time, if the referenced code breaks in an unexpected time. Your time is much more valuable than disk space. A gigabyte of disk space costs about $0.10, so even if you value your time at a very conservative rate of $100 / hour, you should only spend an hour of your time reducing package size if it saves at least 1 TB of disk space. That's a lot of copies of a function! Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
r63654 has fixed this particular issue, and R-devel will no longer warn against the use of ::: on packages of the same maintainer. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Web: http://yihui.name Department of Statistics, Iowa State University 102 Snedecor Hall, Ames, IA On Thu, Aug 22, 2013 at 6:45 AM, Uwe Ligges lig...@statistik.tu-dortmund.de wrote: On 22.08.2013 07:45, Yihui Xie wrote: Hi, So now R CMD check starts to warn against :::, but I believe sometimes it is legitimate to use it when developing R packages. For example, I have some utils functions that are not exported but I want to share them across the packages that I maintain. I do not need to coordinate with other authors about these internal functions since I'm the only author and I know clearly what I'm doing, and I want to avoid copying and pasting the code across packages just to avoid the NOTE in R CMD check. What should I do in this case? Nothing. The way you describe above seems to be a reasonable usage, iff you are the same maintainer who knows what is going on. Other maintainers should not use one of your not exported (hence non API) functions, of course. Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Thu, Aug 22, 2013 at 2:03 PM, Hadley Wickham h.wick...@gmail.com wrote: To avoid the NOTEs (which often triggers a 'pls fix' upon submission to CRAN), I simply copied/pasted these functions to my package, but this seems wasteful. Wasteful of disk space, but disk space is cheap. It's less wasteful of your time, if the referenced code breaks in an unexpected time. Your time is much more valuable than disk space. A gigabyte of disk space costs about $0.10, so even if you value your time at a very conservative rate of $100 / hour, you should only spend an hour of your time reducing package size if it saves at least 1 TB of disk space. That's a lot of copies of a function! A bigger issue is source-code license conflicts; you may cut'n'paste GPL code into a distribution that is under another license. /Henrik Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Thu, Aug 22, 2013 at 2:03 PM, Hadley Wickham h.wick...@gmail.com wrote: To avoid the NOTEs (which often triggers a 'pls fix' upon submission to CRAN), I simply copied/pasted these functions to my package, but this seems wasteful. Wasteful of disk space, but disk space is cheap. It's less wasteful of your time, if the referenced code breaks in an unexpected time. Your time is much more valuable than disk space. On the other hand, it's quite dangerous software design. What if the original author finds a bug and implements a fix, but you don't hear about it? Furthermore, what happens when I come along and need the same functionality? Sure I could make a copy, but maybe I only know about your copy and don't know it is a copy of something else, so now we have a copy of a copy, which is even more problematic. Using ::: prevents this issue. Using ::: also allows us to get the credit for the idea/functionality right, which is important and which our field could stand for some improvement on. I would argue, though, in response to the original question that if you have functions that you, yourself are using in multiple packages, or that you know other people are going to want to use, that is an indication that the function is broadly useful and really should be exported from somewhere (either the package it lives in now or a lightweight dependency/utility package where you collect all such functions you create). The much muddier issue is what to do when someone has written a function that *almost* does what you want, but has a hardcoded limitation in it that prevents you from using it. That situation is harder to deal with imo unless the maintainer of the package is open to patches/pull requests. ~G -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Wasteful of disk space, but disk space is cheap. It's less wasteful of your time, if the referenced code breaks in an unexpected time. Your time is much more valuable than disk space. On the other hand, it's quite dangerous software design. What if the original author finds a bug and implements a fix, but you don't hear about it? Furthermore, what happens when I come along and need the same functionality? Sure I could make a copy, but maybe I only know about your copy and don't know it is a copy of something else, so now we have a copy of a copy, which is even more problematic. Using ::: prevents this issue. There are costs and benefits to both approaches. Copy-and-paste also minimises external dependencies which can be important in some cases. I'm not arguing for unmitigated duplication, but there are definitely good reasons to do it. I have quite a few v. simple functions that live in multiple packages. Often I want to keep the dependencies of packages as lightweight as possible (learning from past experiences) and avoid tightly coupling packages together. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Dear Peter, -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- project.org] On Behalf Of peter dalgaard Sent: Thursday, August 22, 2013 4:45 PM To: Michael Friendly Cc: R-devel; Uwe Ligges Subject: Re: [Rd] legitimate use of ::: On Aug 22, 2013, at 20:57 , Michael Friendly wrote: Cases in point: in heplots, I had used stats:::Pillai, stats:::Wilks, stats:::Roy and stats:::LH for calculation in one of my functions. That particular case has been on what remains of my conscience for some time Happily, it would be easy to relieve your conscience in this matter. Best, John -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Another point to consider is that copying someone else's code forces you to become a maintainer of the copied code. If there are any bug fixes/enhancements/what-have-you in the original you won't get those updates. So now you own the copied code and need to consider the cost of the codebase diverging (from the original). On Aug 22, 2013, at 5:03 PM, Hadley Wickham h.wick...@gmail.com wrote: To avoid the NOTEs (which often triggers a 'pls fix' upon submission to CRAN), I simply copied/pasted these functions to my package, but this seems wasteful. Wasteful of disk space, but disk space is cheap. It's less wasteful of your time, if the referenced code breaks in an unexpected time. Your time is much more valuable than disk space. A gigabyte of disk space costs about $0.10, so even if you value your time at a very conservative rate of $100 / hour, you should only spend an hour of your time reducing package size if it saves at least 1 TB of disk space. That's a lot of copies of a function! Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Thu, Aug 22, 2013 at 4:52 PM, Brian Rowe r...@muxspace.com wrote: Another point to consider is that copying someone else's code forces you to become a maintainer of the copied code. If there are any bug fixes/enhancements/what-have-you in the original you won't get those updates. So now you own the copied code and need to consider the cost of the codebase diverging (from the original). Sometimes that's a good thing - you're equally insulated from the original maintainer changing the function to work in a way that you don't like. Again, I'm not arguing that copy-and-paste is necessarily the right solution, but it's not necessarily the wrong solution either - it depends on the context. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
If ::: is disallowed then its likely that package developers will need to export more functions to satisfy the consumers of those otherwise hidden functions but if more functions are exported then there will be a greater likelihood of conflicts among packages. The problem seems to be that there are potentially three sorts of functions here: 1. a function is hidden 2. a function is accessible via ::: but is not on the search path 3. a function is on the search path The problem arises in attempting to force fit these three concepts into only two categories either by removing the first category (as was done previously) or by removing the second category (which seems to be the new approach). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
You raise an interesting point that I've mulled over a bit: namespace collisions. How many of these issues would go away if there were a better mechanism for managing namespaces? eg in other languages you can control which objects/modules you wish to import from a library. Under this regime I think package developers would be less concerned about exposing functions that otherwise would be private. On Aug 22, 2013, at 6:27 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: If ::: is disallowed then its likely that package developers will need to export more functions to satisfy the consumers of those otherwise hidden functions but if more functions are exported then there will be a greater likelihood of conflicts among packages. The problem seems to be that there are potentially three sorts of functions here: 1. a function is hidden 2. a function is accessible via ::: but is not on the search path 3. a function is on the search path The problem arises in attempting to force fit these three concepts into only two categories either by removing the first category (as was done previously) or by removing the second category (which seems to be the new approach). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 23.08.2013 00:36, Brian Lee Yung Rowe wrote: You raise an interesting point that I've mulled over a bit: namespace collisions. How many of these issues would go away if there were a better mechanism for managing namespaces? eg in other languages you can control which objects/modules you wish to import from a library. Under this regime I think package developers would be less concerned about exposing functions that otherwise would be private. Exactly, the corresponding NAMESPACE directive is importFrom() and it should be used. On Aug 22, 2013, at 6:27 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: If ::: is disallowed then its likely that package developers will need to export more functions to satisfy the consumers of those otherwise hidden functions but if more functions are exported then there will be a greater likelihood of conflicts among packages. The problem seems to be that there are potentially three sorts of functions here: 1. a function is hidden 2. a function is accessible via ::: but is not on the search path 3. a function is on the search path Not entirely right: If the package or only parts of it are imported via importFrom by another package, the package is not loaded, hence not on the search path. Best, Uwe Ligges The problem arises in attempting to force fit these three concepts into only two categories either by removing the first category (as was done previously) or by removing the second category (which seems to be the new approach). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Thu, Aug 22, 2013 at 6:41 PM, Uwe Ligges lig...@statistik.tu-dortmund.de wrote: On 23.08.2013 00:36, Brian Lee Yung Rowe wrote: You raise an interesting point that I've mulled over a bit: namespace collisions. How many of these issues would go away if there were a better mechanism for managing namespaces? eg in other languages you can control which objects/modules you wish to import from a library. Under this regime I think package developers would be less concerned about exposing functions that otherwise would be private. Exactly, the corresponding NAMESPACE directive is importFrom() and it should be used. On Aug 22, 2013, at 6:27 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: If ::: is disallowed then its likely that package developers will need to export more functions to satisfy the consumers of those otherwise hidden functions but if more functions are exported then there will be a greater likelihood of conflicts among packages. The problem seems to be that there are potentially three sorts of functions here: 1. a function is hidden 2. a function is accessible via ::: but is not on the search path 3. a function is on the search path Not entirely right: If the package or only parts of it are imported via importFrom by another package, the package is not loaded, hence not on the search path. OK but it is still true that under the new rules to use importFrom(B, f) in package A that f must be exported by B. That implies that f could cause a conflict when B is placed on the search path via library(B) by some other package (package C) or by the user. f is either exported by B or not. If f is exported by B then f will be placed on the search path whenever B is placed on the search path and if f is not exported then A can't import it. That is there is no way for B to declare a function to be importable by another package without having that function also placed on the search path whenever B is loaded by a library(B)l or a Depends: B from another package. on the search path -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
My understanding is that lookup happens in the imports before moving on to the search path, so if I understand you correctly I don't think that is an issue. If A also *exported* f, that would be a problem... From writing R extensions (talking about functions in a package finding variables, sec 1.6): The namespace controls the search strategy for variables used by functions in the package. If not found locally, R searches the package namespace first, then the imports, then the base namespace and then the normal search path. On Thu, Aug 22, 2013 at 4:45 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Thu, Aug 22, 2013 at 6:41 PM, Uwe Ligges lig...@statistik.tu-dortmund.de wrote: On 23.08.2013 00:36, Brian Lee Yung Rowe wrote: You raise an interesting point that I've mulled over a bit: namespace collisions. How many of these issues would go away if there were a better mechanism for managing namespaces? eg in other languages you can control which objects/modules you wish to import from a library. Under this regime I think package developers would be less concerned about exposing functions that otherwise would be private. Exactly, the corresponding NAMESPACE directive is importFrom() and it should be used. On Aug 22, 2013, at 6:27 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: If ::: is disallowed then its likely that package developers will need to export more functions to satisfy the consumers of those otherwise hidden functions but if more functions are exported then there will be a greater likelihood of conflicts among packages. The problem seems to be that there are potentially three sorts of functions here: 1. a function is hidden 2. a function is accessible via ::: but is not on the search path 3. a function is on the search path Not entirely right: If the package or only parts of it are imported via importFrom by another package, the package is not loaded, hence not on the search path. OK but it is still true that under the new rules to use importFrom(B, f) in package A that f must be exported by B. That implies that f could cause a conflict when B is placed on the search path via library(B) by some other package (package C) or by the user. f is either exported by B or not. If f is exported by B then f will be placed on the search path whenever B is placed on the search path and if f is not exported then A can't import it. That is there is no way for B to declare a function to be importable by another package without having that function also placed on the search path whenever B is loaded by a library(B)l or a Depends: B from another package. on the search path -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
It would be nice if the functionality of importFrom() and import() were available to user level code, rather than just to people building packages for distribution. One most often encounters namespace conflicts at the user level, when loading two packages that have no logical connection other than both bearing on your problem of the moment. R conflates having namespaces with having a library distribution mechanism and while its library distribution mechanism is top notch, most modern languages do not require you to learn the distribution procedure in order to just have namespaces. For instance, in Python you merely put code in a file called foo.py and then in any other file in the same directory you type import functionName from foo. I.E. using namespaces does not require you to build/install packages. Python namespaces are also hierarchical so that the question of this thread would easily be resolved by putting functions into foo._internal and in other packages typing import * from foo._internal Peter [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Thu, Aug 22, 2013 at 7:57 PM, Gabriel Becker gmbec...@ucdavis.edu wrote: My understanding is that lookup happens in the imports before moving on to the search path, so if I understand you correctly I don't think that is an issue. If A also *exported* f, that would be a problem... A can only import f from B if f has been exported from B so while its not a problem for A, whenever anyone issues a library(B) f will be visible on the search path -- the problem of potential conflicts with f remains. B really only exported f so that A could import it but a side effect of that is that anyone who puts B on the search path makes f visible. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
(missed the list the first time) Perhaps an importHiddenFrom directive should be added to the namespace vocabulary which can import a non-exported function. The non-exported functions clearly exist somewhere, as package code can use them, so it would not be impossible to allow that (though I'm not saying it would be easy, as I haven't looked at how the namespace stuff is implemented). On Thu, Aug 22, 2013 at 5:19 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Thu, Aug 22, 2013 at 7:57 PM, Gabriel Becker gmbec...@ucdavis.edu wrote: My understanding is that lookup happens in the imports before moving on to the search path, so if I understand you correctly I don't think that is an issue. If A also *exported* f, that would be a problem... A can only import f from B if f has been exported from B so while its not a problem for A, whenever anyone issues a library(B) f will be visible on the search path -- the problem of potential conflicts with f remains. B really only exported f so that A could import it but a side effect of that is that anyone who puts B on the search path makes f visible. -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
This is what I was getting at as well. It would be great to have a call like
require(package, c('funtion.1','function.2'))
or similar that gives users granular control over what gets imported in the
shell. I would be drunk with joy if the same mechanism could be used to
automatically populate the package directives.
On Aug 22, 2013, at 8:01 PM, Peter Meilstrup peter.meilst...@gmail.com wrote:
It would be nice if the functionality of importFrom() and import() were
available to user level code, rather than just to people building packages
for distribution. One most often encounters namespace conflicts at the user
level, when loading two packages that have no logical connection other than
both bearing on your problem of the moment.
R conflates having namespaces with having a library distribution
mechanism and while its library distribution mechanism is top notch, most
modern languages do not require you to learn the distribution procedure in
order to just have namespaces.
For instance, in Python you merely put code in a file called foo.py and
then in any other file in the same directory you type import functionName
from foo. I.E. using namespaces does not require you to build/install
packages. Python namespaces are also hierarchical so that the question of
this thread would easily be resolved by putting functions into
foo._internal and in other packages typing import * from foo._internal
Peter
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Peter Meilstrup: (05:01PM on Thu, Aug 22) One most often encounters namespace conflicts at the user level, when loading two packages that have no logical connection other than both bearing on your problem of the moment. Unless I'm mistaken, you can reassign the hidden functions, ie fna - joespackage:::usefulfunction fnb - janespackage:::usefulfunction which is a little bit of a pain, but makes the user's code unambiguous. This also works with two colons for explicitly exported functions. -- Gray Calhoun, Assistant Professor of Economics at Iowa State http://gray.clhn.co (web) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Dear Gray, On Thu, 22 Aug 2013 19:41:58 -0500 Gray g...@clhn.co wrote: Peter Meilstrup: (05:01PM on Thu, Aug 22) One most often encounters namespace conflicts at the user level, when loading two packages that have no logical connection other than both bearing on your problem of the moment. Unless I'm mistaken, you can reassign the hidden functions, ie fna - joespackage:::usefulfunction fnb - janespackage:::usefulfunction This will now generate a note from R CMD check and an objection from the CRAN administrators. Best, John which is a little bit of a pain, but makes the user's code unambiguous. This also works with two colons for explicitly exported functions. -- Gray Calhoun, Assistant Professor of Economics at Iowa State http://gray.clhn.co (web) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Hey guys, Because I was curious and had nothing else that I should have been doing (that second part is a lie), I looked into the namespace code. I have a working patch that implements importHiddenFrom. It doesn't currently check whether you then export that symbol (which should not be allowed) but that would be easy to implement. Is there any desire from R-core to have add the importHiddenFrom functionality? If so I can add the export check and submit the patch either here or on bugzilla. I figure its a long shot but hey, at least I now know how the namespace stuff works. I do agree with Peter Meilstrup that poking around at the internals of someone else's code is often not a good idea, but as others have pointed out it is done in practice in some fairly high-profile packages, and if its going to happen it seems like it would be nice to indicate as much in the NAMESPACE file. ~G On Thu, Aug 22, 2013 at 5:41 PM, Gray g...@clhn.co wrote: Peter Meilstrup: (05:01PM on Thu, Aug 22) One most often encounters namespace conflicts at the user level, when loading two packages that have no logical connection other than both bearing on your problem of the moment. Unless I'm mistaken, you can reassign the hidden functions, ie fna - joespackage:::usefulfunction fnb - janespackage:::usefulfunction which is a little bit of a pain, but makes the user's code unambiguous. This also works with two colons for explicitly exported functions. -- Gray Calhoun, Assistant Professor of Economics at Iowa State http://gray.clhn.co (web) __** R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/**listinfo/r-develhttps://stat.ethz.ch/mailman/listinfo/r-devel -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Maybe it is not a good idea for R CMD check to check ::: at all, and a
warning in R-exts and ?':::' may well be enough. On the other hand, it
is just so easy to get around :::, because everybody can see its
source code:
`:::`
function (pkg, name)
{
pkg - as.character(substitute(pkg))
name - as.character(substitute(name))
get(name, envir = asNamespace(pkg), inherits = FALSE)
}
Then the package authors who really want to take the risk may start
another hide and seek game, e.g.
`%:::%` = function(pkg, fun) get(fun, envir = asNamespace(pkg),
inherits = FALSE)
'stats' %:::% 'Pillai'
Non-exported functions do not necessarily imply instability. Maybe it
is just because the author is too lazy to document them, or he/she did
not realize these functions happen to be useful for another author.
Although R-devel does not warn against ::: on the packages of the same
maintainer now, these maintainers may change in the future, or one
maintainer can be an author but not maintainer of another package,
from which he/she imports an unexported function, or package authors
have coordinated well with each other about the unexported functions.
I believe there are other legitimate reasons for :::, which might make
it difficult for R to cover all these cases, and also bring additional
communications between package authors and CRAN.
In conclusion, R CMD check cannot really stop :::, and ::: can be
there for good reasons, so how about just let it go?
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA
On Thu, Aug 22, 2013 at 9:02 PM, Gabriel Becker gmbec...@ucdavis.edu wrote:
Hey guys,
Because I was curious and had nothing else that I should have been doing
(that second part is a lie), I looked into the namespace code.
I have a working patch that implements importHiddenFrom. It doesn't
currently check whether you then export that symbol (which should not be
allowed) but that would be easy to implement.
Is there any desire from R-core to have add the importHiddenFrom
functionality? If so I can add the export check and submit the patch either
here or on bugzilla. I figure its a long shot but hey, at least I now know
how the namespace stuff works.
I do agree with Peter Meilstrup that poking around at the internals of
someone else's code is often not a good idea, but as others have pointed
out it is done in practice in some fairly high-profile packages, and if its
going to happen it seems like it would be nice to indicate as much in the
NAMESPACE file.
~G
On Thu, Aug 22, 2013 at 5:41 PM, Gray g...@clhn.co wrote:
Peter Meilstrup: (05:01PM on Thu, Aug 22)
One most often encounters namespace conflicts at the user level, when
loading two packages that have no logical connection other than both
bearing on your problem of the moment.
Unless I'm mistaken, you can reassign the hidden functions, ie
fna - joespackage:::usefulfunction
fnb - janespackage:::usefulfunction
which is a little bit of a pain, but makes the user's code
unambiguous. This also works with two colons for explicitly exported
functions.
--
Gray Calhoun, Assistant Professor of Economics at Iowa State
http://gray.clhn.co (web)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] legitimate use of :::
Hi, So now R CMD check starts to warn against :::, but I believe sometimes it is legitimate to use it when developing R packages. For example, I have some utils functions that are not exported but I want to share them across the packages that I maintain. I do not need to coordinate with other authors about these internal functions since I'm the only author and I know clearly what I'm doing, and I want to avoid copying and pasting the code across packages just to avoid the NOTE in R CMD check. What should I do in this case? Regards, Yihui -- Yihui Xie xieyi...@gmail.com Web: http://yihui.name Department of Statistics, Iowa State University 102 Snedecor Hall, Ames, IA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
