Hi Gabriel, and thanks for answering. I'm basically just trying to find a way to use the power of `...` in more complex scenarios and I'm well aware that this might not be the best approach ;-)
Regarding your actual question: "Are you suggesting methods be dispatched based on the *contents* of ... [...]?" Yes, I guess currently I kind of do - but not on the argument *names* I'm not expecting functions to detect the argument *names* from `...`, but the relevant "argument containers" from which then the actual arguments should be extracted and used: I thought the *actual* arguments to be passed via `...` to subsequent functions/methods could be put into an "arguments container" (as a list so you could easily use them with `do.call(foo)`) that has a class that `foo` expects for its `...` argument (e.g. `ThreedotsForFoo`). What I would like to accomplish is that `foo` auto-detects those parts coming in via `...` that are *relevant* for itself (e.g. instances of the argument container `ThreedotsForFoo`), that it handles them in a proper way (i.e. extracting the *actual* arguments from the container) and that it passes `...` along to subsequently called functions. That's why I would need methods that use mix of regular formal arguments and `...`. Best regards, Janko On Thu, Nov 27, 2014 at 7:48 PM, Gabriel Becker <gmbec...@ucdavis.edu> wrote: > Janko, > > I'm not entirely sure I understand your proposal. Are you suggesting > methods be dispatched based on the *contents* of ... (ie which arguments > are in there)? This seems like it would be pretty different from how > dispatch behaves now, which is entirely class based. > > Even the dispatching based on ... via dots methods is class based, having > nothing to do AFAIK with the argument names. From ?dotsMethods > > A method selecting on “...” is specified by a single class in the call to > setMethod <http://127.0.0.1:11942/library/methods/help/setMethod>. If all > the actual arguments corresponding to “...” have this class, the > corresponding method is selected directly. > > Otherwise, the class of each argument and that class' superclasses are > computed, beginning with the first “...” argument. For the first argument, > eligible methods are those for any of the classes. For each succeeding > argument that introduces a class not considered previously, the eligible > methods are further restricted to those matching the argument's class or > superclasses. If no further eligible classes exist, the iteration breaks > out and the default method, if any, is selected. > > > No mention of argument name there. > > ~G > > On Thu, Nov 27, 2014 at 9:45 AM, Janko Thyson <janko.thy...@gmail.com> > wrote: > >> Dear List, >> >> I'm currently investigating if the argument dispatch mechanism based on >> `...` could somehow be "generalized" to scenarios that involve `r` >> recipients located across `c` calling stack layers *and* combined with the >> S4 method mechanism (for those interested see >> >> http://stackoverflow.com/questions/26963900/generalizing-three-dots-argument-dispatch-s4-methods-for-argument-set-i >> for an (conceptual) approach of how this could be realized). >> >> AFAICT, this would require that `...` can be *mixed* with other signature >> arguments, which is currently not supported as stated in `?dotsMethods`: >> >> Quote { >> Using "..." in a Signature >> >> Beginning with version 2.8.0 of R, S4 methods can be dispatched (selected >> and called) corresponding to the special argument “...”. Currently, “...” >> cannot be mixed with other formal arguments: either the signature of the >> generic function is “...” only, or it does not contain “...”. (This >> restriction may be lifted in a future version.) >> } >> >> Would it be possible to consider lifting this limitation soon? >> >> Thanks a lot to everyone maintaining R!! >> >> Janko >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > > -- > Gabriel Becker > Graduate Student > Statistics Department > University of California, Davis > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
