[Rd] Handling masked methods

[Martin Maechler]

>>>>> "GA" == Gad Abraham <gabraham at csse.unimelb.edu.au>
>>>>>     on Fri, 17 Jul 2009 10:29:29 +1000 writes:

    GA> On 16/7/09 12:18 PM, Duncan Murdoch wrote:
    >> Gad Abraham wrote:
    >>> Hi,
    >>> 
    >>> Say I have two packages, test1 and test2, that both define the generic
    >>> method train (identical definition), and each has a specific train
    >>> method for a different S4 object (foo and bar, resp.)
    >>> 
    >>> I want to be able to call train(foo, x, y) and train(bar, x, y), which
    >>> doesn't work since test2 masks test1, as seen below.
    >>> 
    >>> The two solutions I can think of are to a) prefix train,
    >>> test1::train(foo) and test2::train(bar), which gets cumbersome for
    >>> non-trivial code, or b) make test2 depend on test1 so it doesn't have
    >>> to define the generic, but I'd rather keep the packages compatible but
    >>> not dependent. Any suggestions?
    >>> 
    >> Two other possibilities:
    >> 
    >> Make just one package, with just one definition, and put all the other
    >> stuff from test1 and test2 into it.

    >> Make a third package to hold the generic, and have both packages depend
    >> on that.

Yes.
A while ago, there was a proposal to provide a small standard
(i.e. in R-base) package, say "generics", depending on 'methods'
which would contain  setGenerics(..) for a set of
generic functions that the R developer community would more or
less agree on.
Then, all packages that define methods for these generics would
just import from "generics" and attach their methods to that one
generic from the "generics" package.


    GA> Thanks, but these approaches only really work if you're the author of 
    GA> both packages. I'm more interested in having compatible packages which 
    GA> just work together, just like predict works on any object.

(in theory!)

    GA> Is there a way to tell R that the two generics are really the same 
    GA> so not to complain about it,

As mentioned, there's the -- albeit asymmetric -- approach
of test2 importing the generic from test1. 
Making R not to complain would be quite wrong IMO, since
you'll have two generics with different methods attached (more
detailled: you have two different method dispatch hash tables in
different namespaces) and that maybe
very problematic, hence should be warned about.
I may not be aware of the latest developments here, and we
should away John Chambers say on this
BTW: Do read

     Chambers, John M.(2009) _Developments in Class Inheritance and
     Method Selection_ <URL:
     http://stat.stanford.edu/~jmc4/classInheritance.pdf>.

{ which is from the "References:" section in  help(Methods) }

    GA>  or alternatively, to search for the method in each
    GA>  object's own package first?

That's a somewhat interesting proposal
which would mean a change (in those relatively rare cases) in 
S4 method dispatch.




    GA> I ended up assigning the respective train method as an attribute to each 
    GA> object, and then extracting that when needed; it works but it's a bit ugly.

    GA> -- 
    GA> Gad Abraham
    GA> MEng Student, Dept. CSSE and NICTA
    GA> The University of Melbourne
    GA> Parkville 3010, Victoria, Australia
    GA> email: gabraham at csse.unimelb.edu.au
    GA> web: http://www.csse.unimelb.edu.au/~gabraham

    GA> ______________________________________________
    GA> R-devel at r-project.org mailing list
    GA> https://stat.ethz.ch/mailman/listinfo/r-devel