On Sat, Aug 24, 2013 at 9:46 AM, 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
On 13-08-26 12:04 PM, Gavin Simpson wrote:
Right Henrik, but then you have to document it or R CMD check raises a
Warning, which is less likely to pass muster when submitting to CRAN.
So you document that method on your existing method's Rd page (just
via an \alias{}), which is fine until the u
I'm not familiar enough with S4 to know what is going on there. With
S3 methods, the package that defines the generic needs to be loaded
and attached, otherwise you can't do
foo(bar)
when
foo.myclass(bar)
is what you want to be called and you export that method from your
package. Calling `foo()
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/20
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 packag
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 s
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
On Mon, Aug 26, 2013 at 1:06 PM, Trevor Davis 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
>> authors
> 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)?
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 p
Or you could import the generic, but not export it, and then use
require("rgl") in examples. That seems reasonable if the majority of
functions don't need other rgl functions.
If most of the time you do need rgl loaded, then Martyn's suggestion
to require rgl seems reasonable.
Hadley
On Mon, Au
Right Henrik, but then you have to document it or R CMD check raises a
Warning, which is less likely to pass muster when submitting to CRAN.
So you document that method on your existing method's Rd page (just
via an \alias{}), which is fine until the user does end up attaching
the original source o
On Mon, Aug 26, 2013 at 1:28 AM, Martyn Plummer wrote:
> I think rgl should be in Depends. You are providing a method for a
> generic function from another package. In order to use your method, you
> want the user to be able to call the generic function without scoping
> (i.e. without calling rgl
> 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
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 fun
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. A
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
I think rgl should be in Depends. You are providing a method for a
generic function from another package. In order to use your method, you
want the user to be able to call the generic function without scoping
(i.e. without calling rgl::plot3d), so the generic should be on the
search path, so the p
18 matches
Mail list logo
