Skip to content

Same class name, different package

4 messages · John Chambers, Martin Maechler

Original
John Chambers
# 
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
3 days later
John Chambers
# 
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
On 7/21/11 10:29 AM, John Chambers wrote:
Martin Maechler
# 
> 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.

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
John Chambers
#
On 7/25/11 12:07 AM, Martin Maechler wrote:
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.)

John