>>>>> "GA" == Gad Abraham <gabra...@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: gabra...@csse.unimelb.edu.au
GA> web: http://www.csse.unimelb.edu.au/~gabraham
GA> ______________________________________________
GA> R-devel@r-project.org mailing list
GA> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
