On 7/25/11 12:07 AM, Martin Maechler wrote:
>>>>>> John Chambers<
[hidden email]>
>>>>>> 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.)
John
>
> 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
>
> ______________________________________________
>
[hidden email] mailing list
>
https://stat.ethz.ch/mailman/listinfo/r-devel>
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Locked
