[Rd] package slot of generic "[" and missing env at target?

Hin-Tak Leung hintak_leung at yahoo.co.uk
Fri Jun 22 12:14:22 CEST 2012

--- On Thu, 21/6/12, Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:

> Hi,
> Since upgraded to R 2.15, I have a problem with duplicate S4
> class name no longer works (the reason for having duplicate
> S4 class names is just software forks - they are largely
> identical but don't have an inheritence relationship, and
> will never have such). 
> This is happening with "library(mypackage2)" :
> Error: package slot missing from signature for generic
> ‘[’
> and classes myclass, ANY, ANY, ANY
> cannot use with duplicate class names (the package may need
> to be re-installed)
> I have done "debug(methods:::.pkgMethodLabel)" and found
> that curiously, it is invoked for the two copies of the "["
> generic with signature "classes myclass, ANY, ANY, ANY",
> ones with 
> packageSlot(method at target) sets to c("mypackage2",
> "methods", "methods", "methods"), the other just c("", "",
> "",""), instead of  
> c("mypackage1", "methods", "methods", "methods").
> So in the R debugger, I modified the packageSlot() directly,
> and get library(mypacakge2) to finish loading, a few times
> (once in a while R craps out with some error message about
> LANGSXP - I know it is probably a bad idea to modify data
> structures within the debugger, so that's probably
> expected).
> So my next step was simply to patch R/library/methods to
> downgrade the stop() to a warning(), as well as inserting
> the missing packageSlot values there and then.
> This got both packages loaded. But then, some actual use of
> "[", it gives this error instead:
> Error in .methodPackageSlots(def, label, table, dupl,
> isCurrent) : 
>   trying to get slot "target" from an object of a basic
> class ("environment") with no slots
> and when I downgrade this error to a warning again,
> modifying (src/main/attrib.c) I got "[" dispatched to the
> base class (as well as stack imbalance - the latter is
> expected and "asking for it"...).
> Anyway, I am thinking:
> - doing "debug(methods:::.pkgMethodLabel)", I see two "[" of
> signature "classes myclass, ANY, ANY, ANY", one comes with
> packageSlot with the correct stuff and one with just 4 "",
> that seems to be a bug?
> - from the warning at the beginning: 
> "A specification for class “myclass” in package
> ‘mypackage1’ seems equivalent to one from package
> ‘mypackage2’ and is not turning on duplicate class
> definitions for this class"
> It would appear that there is a "correct" way of turning on
> duplicate class definition, but I have not found any
> documentation to that effect.
> I see some discussion about class unions, and inheritances,
> but in this case, neither are appropriate - the two packages
> are just forks and have no union nor inheritance
> relationship; but it is desirable to load both, to check for
> differences and bugs.
> - I am also curious why only "[" triggers the problem, but
> not "[<-" or another of the other duplicated methods.
> Obviously subsetting is being treated specially, as is
> mentioned a few times in R internals; but I was expecting
> subassignment to be affected also, and that does not seems
> to be the case.
> Anyhow, it is an extremely useful feature to be able to load
> a past version of a package simultaneously just by renaming
> the package name and namespace, to check for regression and
> change-in-behavior, i.e. newly added bugs; so I am hoping to
> get this working again.
> TIA.

Found a small work-around - whenever I want to switch, just do

detach("package:package1", unload=TRUE)
library(package2, quietly=TRUE)

or vice versa. A bit tedious, also documentation says detach() doesn't always work as planned.  (with 'echo=FALSE' in Sweave, the resulting tex doesn't even change at all). There are also a dozen of:

Warning in FUN(X[[1L]], ...) :
  Created a package name, ‘2012-06-22 10:58:02’, when none found

whenever detach() + library() is done. Still  would appreciate clarification of the missing package slot in '[' generic (and whether it is a bug) and other matters.

More information about the R-devel mailing list