For the record: I've checked this in R 3.5.0 and R 3.4.4, and in both cases
this problem exists.
Also, I need to correct myself: The correct way to document with roxygen is
to use _both_ the @method and @export tag:
@method foo bar
@export
That registers the S3 method correctly (and hence doesn't export the method
itself).
On Thu, Jul 5, 2018 at 4:18 PM, Joris Meys <joris.m...@ugent.be> wrote:
> 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
>
--
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>
tel: +32 (0)9 264 61 79
-----------
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
