[ESS] ess-developer and S3 methods

[Andreas Leha]

Hi Vitalie,

Vitalie Spinu <spinuvit at gmail.com> writes:

> This is sort of a "feature" forcing people to use S4 :P.

;-)  Why not go directly to reference classes then and limit support for
S4 as well? ;-)


> I have the
> following comment in ESSR/developer.R:
>
>    ## COMMENT ON S3 METHODS: It is not feasible and, quite frankly, a bad practice
>    ## to check all the assigned function names for "." separator. Thus, S3 methods
>    ## are not automatically registered. You can register them manually after you
>    ## have inserted method_name.my_class into your package environment using
>    ## ess-developer, like follows:
>    ##
>    ##    registerS3method("method_name", "my_class", my_package:::method_name.my_class)
>    ##
>    ## Otherwise R will call the registered (i.e. cached) S3 method instead of the
>    ## new method that ess-developer inserted in the package environment.
>
> If I remember correctly, R doesn't provide a way to check whether a
> function is a registered S3 method and I would have to check every
> attached namespace for S3 tables.  Now I forgot the details but I see
> the handling of local S3 tables in developer.R. So if you evaluate an S3
> meethods for a generic which is defined in the same package, everything
> should be fine. For generics defined in other packages, you are out of
> luck.
>
> Anyways, patches are welcome. If you have an idea of how to check for S3
> methods, let me know.

I do not have a good idea, sorry.  But I do document my package using
roxygen2, so I have a roxygen tag
  @method predict foo
before the function.
So a very simple idea for ess-developer would be to do the registration
at least if such tag is present.

I am not sure if it is a good idea to take that hint (if present) in
ess-developer, especially as in roxygen3 that tag is not necessary,
IIUC.

[...]

Anyway, thanks for the answer and the manual work-around.

- Andreas