I see that you realized it was Inaki who gave you he patch, not me :-)
I've been looking into this further, and the toy example David put up is
actually not the right one to look at. In that example the generic is
created in the namespace. But in the original huxtable that was not the
case. Try the following :
foo.barrista <- function(x, ...){
cat("In barrista\n")
}
make_a_method <- function (x){
assign("foo", function(x, ...){
UseMethod("foo")
} ,envir = getNamespace('testMethod'))
assign("foo.bar", function (x, ...) cat("In foo.bar"),
envir = getNamespace('testMethod'))
}
make_a_method()
With a namespace:
S3method(foo,bar)
S3method(foo,barrista)
export(foo)
And test code :
thebar <- structure(1, class = c("bar", "data.frame"))
thebarrista <- structure(1, class = "barrista")
foo(thebarrista)
foo(thebar)
In both cases the correct method cannot be found. When the methods are both
exported and registered (i.e. add export(foo.bar) and export(foo.barrista)
to NAMESPACE), everything goes fine again on Windows.I went back to the
original version you sent to CRAN, and that doesn't cause any problems on
Windows either. So when the methods are exported and registered, the
problem apparently only exists on Linux.
The other thing I've noticed, is that align() is called from within the
function huxtable() without problem. So the method is found when the
generic is called by a function in the namespace, but not when the generic
is called from the global env. The patch of Inaki makes sure that the
_generic_ is assigned in the namespace itself instead of a child
environment.
To the previous minimal example, add:
baz <- function(x) foo(x)
and to the NAMESPACE:
export(baz)
If you try now:
baz(thebar)
baz(thebarrista)
the correct methods are found. But foo(thebar) etc still doesn't find the
correct ones.
On a sidenote: roxygen is really not helping here. @export literally
exports all these methods as they're not recognized as S3methods. So here
you actually need the deprecated tag @S3method. I wish Hadley would revert
the deprecation, as @export fails to recognize S3 methods correctly in
other cases as well.
On Thu, Jul 5, 2018 at 1:19 PM, Duncan Murdoch <murdoch.dun...@gmail.com>
wrote:
> On 05/07/2018 5:22 AM, David Hugh-Jones wrote:
>
>>
>> Wow, this is extremely helpful. I've applied Joris' patch. By the way,
>> the github master has the change that I stopped exporting methods, as per
>> Hadley's suggestion; this caused *all* functions created via
>> make_getter_setters to fail. Version 4.0.1 on CRAN has the methods
>> exported, which was masking the error in most cases. I don't know why
>> bold() was failing in certain cases only... in any case, the patch seems to
>> fix things.
>>
>>
> That's a roxygen2 bug or misuse. If you use the code below without the
> roxygen2 processing, and manually build the NAMESPACE file as
>
> export(foo)
> S3method(foo, bar)
>
> then things are fine. I don't know roxygen2 well enough to know what else
> you should have done to get your NAMESPACE file to look like that.
>
> Duncan Murdoch
>
>
> Here is a brief test case that shows the original problem. I don't know
>> whether this reveals any problem in base R:
>>
>> # in package mypackage:
>> #' @export
>> foo <- function (x, ...) UseMethod('foo')
>> make_a_method <- function () assign("foo.bar", function (x, ...) cat("In
>> foo.bar"), pos = getNamespace('mypackage'))
>> make_a_method()
>>
>> # in the console:
>> library(mypackage)
>> mypackage:::foo.bar
>> ## function (x, ...) cat("In foo.bar")
>> ## <bytecode: 0x109a0ab80>
>> ## <environment: 0x109a0ba28>
>> x <- structure(1, class='bar')
>> foo(x)
>> ## Error in UseMethod("foo") :
>> ## no applicable method for 'foo' applied to an object of class "bar"
>>
>> Also, I know I shouldn't be using @s3method ... it's on the TODO list... !
>>
>> Cheers,
>> David
>>
>>
>> On Thu, 5 Jul 2018 at 09:07, Iñaki Úcar <i.uca...@gmail.com <mailto:
>> i.uca...@gmail.com>> wrote:
>>
>> El mié., 4 jul. 2018 a las 22:47, Duncan Murdoch
>> (<murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>>)
>> escribió:
>> >
>> > On 04/07/2018 4:04 PM, Joris Meys wrote:
>> > >
>> > >
>> > > On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch
>> <murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>
>> > > <mailto:murdoch.dun...@gmail.com
>>
>> <mailto:murdoch.dun...@gmail.com>>> wrote:
>> > >
>> > >
>> > > That shouldn't matter. That function was created in a local
>> > > environment whose parent is <environment: namespace:huxtable>
>> > > (probably by the huxtable:::make_setter_getters function,
>> but I
>> > > didn't check).
>> > >
>> > > Duncan Murdoch
>> > >
>> > > I would think it does matter. Methods are found on the search
>> path, but
>> > > the environment where the methods are defined is not on the
>> search path.
>> > > It's a child environment of the namespace, and hence cannot be
>> reached
>> > > from either the global environment or the namespace if I
>> understood it
>> > > correctly.
>> > >
>> >
>> > The environment of a function is where it looks for objects, not
>> where
>> > it is stored. That method is stored in the huxtable namespace, and
>> > exported from it. That's why
>> > getFromNamespace("align.huxtable","huxtable") (or even
>> > huxtable::align.huxtable) finds it.
>> >
>> > I don't know the source of the original error.
>>
>> I don't know either. But obviously it has something to do with the
>> function environment and how UseMethod looks for methods when they are
>> exported from a namespace (I tested a similar "layout" in the global
>> environment and the method is correctly found). So maybe this thread
>> belongs to r-devel instead.
>>
>> Iñaki
>>
>> >
>> > Duncan Murdoch
>> >
>>
>> ______________________________________________
>> R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
>> mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>
> ______________________________________________
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
-----------
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
