Re: [Rd] Same class name, different package

From: John Chambers <>
Date: Mon, 25 Jul 2011 17:45:14 -0700

On 7/25/11 12:07 AM, Martin Maechler wrote:
>>>>>> John Chambers<>
>>>>>> on Sun, 24 Jul 2011 14:58:23 -0700 writes:
> > A point that has come up a couple of times with the new
> > test is that two classes from two packages may be "the
> > same class". Should that turn on duplicate classes?
> > One situation where the answer seems to be No is when the
> > two classes are identical declarations of S3 classes, via
> > setOldClass().
> > A recent update (rev. 56492) tries to check for equivalent
> > classes, with some special leeway for that case, and does
> > not turn on the duplicate class flag. It's not clear what
> > is really needed or wanted in all circumstances, so
> > further experience will be helpful.
> > If duplicate classes do exist, a utility
> > findDuplicateClasses(details = FALSE) will give the names
> > of the duplicated classes. It's not yet exported so you
> > need to call methods:::findDuplicateClasses()
> > John
> I haven't yet looked into the many situations that are "out
> there" for CRAN and Bioconductor packages and am just speaking
> from my own S4-using perspective:
> I think
> ImportClassesFrom(...)
> should be much more widely used, in order to diminish such class
> "conflicts".
> Wherever the new code produces warnings (does it?) about
> duplicate class names, it would be good to "advertize" the
> ImportClassesFrom() clause for those cases where the two
> class definitions look to be identical.

No argument there.

But I think the situation is different for setOldClass() and for "real" S4 classes, with a warning more suitable in the second case.

With S3 classes, the scenario that will happen fairly often is: Package A has an S3 class "foo"; Packages B and C both (independently) want to use/extend that class in S4 code. Both will include setOldClass("foo") calls.

The problem here is that the two generated classes for "foo" will belong to packages B and C (there being no way in general to find where S3 class "foo" is defined--indeed in a sense it's not defined at all).

Various approaches are possible, varying in ugliness. One might be to associate all these converted S3 classes with a special pseudo-package.   Another, which I don't much like, is to ask the setOldClass() call to specify which package the S3 class comes from, and hope that all the packages in the above scenario make the same choice.

The short term approach will probably be to allow multiple identical setOldClass() effects without warning. (The actual code as of today generates warning messages on all identical classes only if options(warn=1) has been set.)


> Martin
> > On 7/21/11 10:29 AM, John Chambers wrote:
> >> In principle, two separately developed packages could use
> >> the same class name, and a user could then attach both
> >> and attempt to use methods for both classes.
> >>
> >> That has never worked, but some changes have been added
> >> to r-devel to handle this case. The changes involve
> >> extending the "signature" class to include package
> >> information. For compatibility, packages will need to be
> >> re-installed from a version of R labelled 56466 or later,
> >> although an attempt is made to fill in missing
> >> information.
> >>
> >> John
> ______________________________________________
> mailing list
> mailing list Received on Tue 26 Jul 2011 - 00:47:49 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Tue 26 Jul 2011 - 09:20:12 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive