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))
na
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) b
Dear Gray,
On Thu, 22 Aug 2013 19:41:58 -0500
Gray 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.
>
> Un
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 <- joes
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
On Thu, Aug 22, 2013 at 2:26 PM, Gabriel Becker wrote:
> On Thu, Aug 22, 2013 at 2:03 PM, Hadley Wickham
> 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.
>
> >Was
(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
On Thu, Aug 22, 2013 at 7:57 PM, Gabriel Becker 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
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
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
On Thu, Aug 22, 2013 at 6:41 PM, Uwe Ligges
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
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 w
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 th
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 ar
On Thu, Aug 22, 2013 at 4:52 PM, Brian Rowe 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 co
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
div
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 2
>>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 i
On Thu, Aug 22, 2013 at 2:03 PM, Hadley Wickham 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
>yo
On Thu, Aug 22, 2013 at 2:03 PM, Hadley Wickham 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
>
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
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
> 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.
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
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,
On Aug 22, 2013, at 15:33, Henrik Bengtsson wrote:
> On Thu, Aug 22, 2013 at 10:05 AM, R. Michael Weylandt
> wrote:
>>
>>
>> On Aug 22, 2013, at 9:09, Michael Friendly wrote:
>>
>>> In checking my vcdExtra package, the following NOTE newly appeared
>>> (R-Forge, using R version 3.0.1 Pat
On Thu, Aug 22, 2013 at 10:05 AM, R. Michael Weylandt
wrote:
>
>
> On Aug 22, 2013, at 9:09, Michael Friendly wrote:
>
>> In checking my vcdExtra package, the following NOTE newly appeared (R-Forge,
>> using R version 3.0.1 Patched (2013-08-20 r63635))
>>
>> Package in Depends field not importe
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
th
On Aug 22, 2013, at 9:09, Michael Friendly wrote:
> In checking my vcdExtra package, the following NOTE newly appeared (R-Forge,
> using R version 3.0.1 Patched (2013-08-20 r63635))
>
> Package in Depends field not imported from: ‘gnm’
> These packages needs to imported from for the case whe
In checking my vcdExtra package, the following NOTE newly appeared
(R-Forge, using R version 3.0.1 Patched (2013-08-20 r63635))
Package in Depends field not imported from: ‘gnm’
These packages needs to imported from for the case when
this namespace is loaded but not attached.
In the DESCRIP
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
30 matches
Mail list logo
