Michael Friendly frien...@yorku.ca
on Wed, 16 Jan 2013 12:52:15 -0500 writes:
On 1/16/2013 12:26 PM, John Fox wrote:
Dear Duncan and Michael,
My initial reaction is that I'd rather not export these
functions from the car package since the package already
has
A new function in my heplots package wants to use a non-exported utility
function in the car package,
df.terms, but this depends on other non-exported functions.
From the Writing R extensions manual, I thought I could do this via (in
my NAMESPACE)
importFrom(car, car:::df.terms,
On 13-01-16 11:25 AM, Michael Friendly wrote:
A new function in my heplots package wants to use a non-exported utility
function in the car package,
df.terms, but this depends on other non-exported functions.
From the Writing R extensions manual, I thought I could do this via (in
my NAMESPACE)
On 1/16/2013 11:40 AM, Duncan Murdoch wrote:
\S 1.6.1 of the manual says regarding importFrom():
Using |foo:::f| instead of |foo::f| allows access to unexported objects.
This is generally not recommended, as the semantics of unexported
objects may be changed by the package author in routine
On 1/16/2013 11:40 AM, Duncan Murdoch wrote:
2. Is my only alternative to copy these functions to my package, also
unexported?
Using car:::df.terms explicitly is another option.
Another possibility is for the car maintainer (John Fox) to export
that function from car.
Hmm. It turns out
Dear Duncan and Michael,
My initial reaction is that I'd rather not export these functions from the car
package since the package already has many exported functions and the functions
in question perform low-level operations that won't be of interest to end
users. I recognize, however, the
On 1/16/2013 12:26 PM, John Fox wrote:
Dear Duncan and Michael,
My initial reaction is that I'd rather not export these functions from the car
package since the package already has many exported functions and the functions
in question perform low-level operations that won't be of interest to
