R devel - Jan 2009 - Inherited Methods in r-devel (for package maintainers mainly)

A recently committed revison of R-devel (47740) has introduced a new 
mechanism for ordering superclasses consistently, with related changes 
for selecting inherited methods.

As part of the process, a function testInheritedMethods has been  
introduced that examines method selection for the relevant subclasses 
and reports ambiguities.

Maintainers of packages that have methods involving multiple arguments 
are encouraged to run testInheritedMethods for the relevant generic 
functions (e.g., the binary operators).  The new method selection is 
unambiguous for single-argument selection.

It's preferable  to find such ambiguities during package development or 
revision, rather than having users encounter ambiguous method selection 
later on.  In that spirit, ambiguous method selection is no longer a 
warning, just a message.

The new mechanism for class ordering and method selection is described 
in a draft paper at http://stat.stanford.edu/~jmc4/classInheritance.pdf 
(later likely to be part of a submission to the R Journal).

John

These changes have been reverted (temporarily, I strongly hope) to sort 
out some incompatibilities with the Matrix recommended package.  They 
will be available on a branch for experimentation, once I sort out how 
to work with svn branches.

John

John Chambers wrote:
> A recently committed revison of R-devel (47740) has introduced a new 
> mechanism for ordering superclasses consistently, with related changes 
> for selecting inherited methods.
>
> As part of the process, a function testInheritedMethods has been  
> introduced that examines method selection for the relevant subclasses 
> and reports ambiguities.
>
> Maintainers of packages that have methods involving multiple arguments 
> are encouraged to run testInheritedMethods for the relevant generic 
> functions (e.g., the binary operators).  The new method selection is 
> unambiguous for single-argument selection.
>
> It's preferable  to find such ambiguities during package development 
> or revision, rather than having users encounter ambiguous method 
> selection later on.  In that spirit, ambiguous method selection is no 
> longer a warning, just a message.
>
> The new mechanism for class ordering and method selection is described 
> in a draft paper at 
> http://stat.stanford.edu/~jmc4/classInheritance.pdf (later likely to 
> be part of a submission to the R Journal).
>
> John
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

The revisions below have been re-committed (r47803), and appear to be 
compatible with the current Matrix package ('0.999375-19').  Thanks to 
Martin Maechler for help with Matrix.

John Chambers wrote:
> A recently committed revison of R-devel (47740) has introduced a new 
> mechanism for ordering superclasses consistently, with related changes 
> for selecting inherited methods.
>
> As part of the process, a function testInheritedMethods has been  
> introduced that examines method selection for the relevant subclasses 
> and reports ambiguities.
>
> Maintainers of packages that have methods involving multiple arguments 
> are encouraged to run testInheritedMethods for the relevant generic 
> functions (e.g., the binary operators).  The new method selection is 
> unambiguous for single-argument selection.
>
> It's preferable  to find such ambiguities during package development 
> or revision, rather than having users encounter ambiguous method 
> selection later on.  In that spirit, ambiguous method selection is no 
> longer a warning, just a message.
>
> The new mechanism for class ordering and method selection is described 
> in a draft paper at 
> http://stat.stanford.edu/~jmc4/classInheritance.pdf (later likely to 
> be part of a submission to the R Journal).
>
> John
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>