[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ess-help
Subject:    Re: [ESS] suggestion: eldoc support for S4 methods
From:       Kasper Daniel Hansen <kasperdanielhansen () gmail ! com>
Date:       2013-05-18 18:47:45
Message-ID: CAC2h7uu7vw4mX6cz2mPuu2_byf+b=-0qhxEB+pUvsiiyFt=j8w () mail ! gmail ! com
[Download RAW message or body]

On Sat, May 18, 2013 at 9:57 AM, Michael Lawrence <lawrence.michael@gene.com
> wrote:

> On Sat, May 18, 2013 at 6:45 AM, Vitalie Spinu <spinuvit@gmail.com> wrote:
>
> >
> > It does work for S3 methods, all arguments sown after || are not from
> > generic.
> >
> > ESS heavily relies on internal R completion. I asked Deepayan Sarkar
> > (the author of R's completion) several years ago if it would be possible
> > to dispatch on first argument, and he ruled it out as inefficient and
> > not worth it in terms of the benefits it brings.
> >
> > I tend to agree with that, because S4 methods usually use the same
> > arguments as the generic so it's really not a big deal. I am a heavy
> > user of S4 and with current eldoc I almost never have a need for this
> > feature.
> >
> >
> Ok, well, in Bioconductor, we tend to define our generics very generically,
> with most having the signature function(x, ...) and the methods having many
> arguments. This happens very often with S3 generics, as well. So I don't
> really agree with Deepayan's opinion. I'm constantly frustrated by the need
> to use selectMethod() or the help to see argument lists.


I will second Michael's usage request here. How S4 is used is quite
different from project to project, but Bioconductor is certainly a big
group and we have may cross-packages generics which - as Michael says -
tend to heavily use that a specific method may have different arguments.

In fact I dare say that our experience - based on quite a lot of time and
testing - is that one should only define arguments in the generic if they
are being dispatched upon.

Best,
Kasper




> > I also don't yet see a convenient user workflow. When you say "on
> > demand" do you mean a reserved key for eldoc invocation with evaluation
> > of arguments? That might be a good idea, any suggestions for a key
> > binding?
> >
> >
> Yes, that's what I meant. I'll defer to you on the keybinding, because
> you're more aware of the key bindings that exist.
>
>
>
> >
> >     Vitalie
> >
> >  >> Michael Lawrence <lawrence.michael@gene.com>
> >  >> on Sat, 18 May 2013 06:19:34 -0700 wrote:
> >
> >  > I really like the new eldoc that is turned on in 13.04, and it would
> be
> >  > cool to make it work on S4 methods. Right now, it accesses only the
> >  > generic, which is often insufficient, because S4 methods will add
> > arguments
> >  > as allowed by the presence of "..." in the generic formals.
> >
> >  > Having no idea of how this works inside ESS, I thought that if you
> could
> >  > somehow get the text of the call, you could use selectMethod() to find
> > the
> >  > actual method. I threw together the function below just for fun. It
> > takes a
> >  > string representation of an R call, parses it, evaluates the
> arguments,
> >  > matches them to elements of the generic signature, and resolves the
> > method.
> >  > It even handles the ".local" delegation that happens when methods add
> >  > formal arguments as mentioned. The evaluation of the arguments might
> be
> >  > expensive, so this should be on-demand only.
> >
> >  > parseToSelectMethod <- function(expr) {
> >  >     call <- parse(text = expr)[[1]]
> >  >     generic <- match.fun(call[[1]])
> >  >     matched.call <- match.call(generic, call)
> >  >     args <- lapply(as.list(matched.call[-1]), eval, parent.frame())
> >  >     classes <- vapply(args, class, character(1))
> >  >     classes.sig <- classes[generic@signature]
> >  >     method <- selectMethod(generic, classes.sig)
> >  >     method.body <- body(method)[[2]]
> >  >     has.local <- identical(quote(`<-`(.local)), method.body[1:2])
> >  >     if (has.local) {
> >  >         method <- method.body[[3]]
> >  >     }
> >  >     method
> >  > }
> >
> >  > Hope that helps some,
> >  > Michael
> >
> >  >      [[alternative HTML version deleted]]
> >
> >  > ______________________________________________
> >  > ESS-help@r-project.org mailing list
> >  > https://stat.ethz.ch/mailman/listinfo/ess-help
> >
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help
>

	[[alternative HTML version deleted]]

______________________________________________
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
[prev in list] [next in list] [prev in thread] [next in thread]