> Michael Friendly
> 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
>> ha
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 e
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 func
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
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
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)
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, car:::df.terms.
