As I mentioned earlier in the thread, the main hangup remains the
treatment of implicit generics--the kludge that turns on method dispatch
for a function in another package, unique() in your original example.
For 2.15.0, my current plan is to make the export/import of implicit
generics as
On 12/18/2011 11:04 AM, John Chambers wrote:
On 12/17/11 6:02 AM, Michael Lawrence wrote:
I guess what it boils down to is whether it makes sense for PkgB to have
exportMethods(unique) when PkgB does not export(unique) or have PkgA in
Depends. And whether it makes sense for PkgC to have
On 12/17/11 6:02 AM, Michael Lawrence wrote:
I guess what it boils down to is whether it makes sense for PkgB to have
exportMethods(unique) when PkgB does not export(unique) or have PkgA in
Depends. And whether it makes sense for PkgC to have
importMethodsFrom(PkgB, unique) without
I guess what it boils down to is whether it makes sense for PkgB to have
exportMethods(unique) when PkgB does not export(unique) or have PkgA in
Depends. And whether it makes sense for PkgC to have
importMethodsFrom(PkgB, unique) without importFrom(PkgA, unique). If it is
not feasible/sensible to
tar of Pkgs A, B, C attached. Martin
On 12/15/2011 03:34 PM, Martin Morgan wrote:
In
R.version.string
[1] R Under development (unstable) (2011-12-15 r57901)
section 1.6.6 of 'Writing R Extensions' says
Note that exporting methods on a generic in the namespace will
also export the generic,
The subject heading is correct if referring to exportMethods() and
importMethodsFrom(). They refer to the methods tables, not the generic
functions, whatever the extensions manual says.
Looking into the code of namespaceImportMethods() will illustrate this.
It just deals with lists of
On 12/16/2011 12:19 PM, John Chambers wrote:
The subject heading is correct if referring to exportMethods() and
importMethodsFrom(). They refer to the methods tables, not the generic
functions, whatever the extensions manual says.
Looking into the code of namespaceImportMethods() will
The key point here is that setGeneric(unique) is done that way,
without other argument, whoever does it. That creates the generic from
the implicit generic corresponding to base::unique. If package A had
done anything else, the resulting methods tables would NOT refer to
package base but to
In
R.version.string
[1] R Under development (unstable) (2011-12-15 r57901)
section 1.6.6 of 'Writing R Extensions' says
Note that exporting methods on a generic in the namespace will
also export the generic, and exporting a generic in the
namespace will also export its methods.
and
