[Rd] Feature request: mixing `...` (three dots) with other formal arguments in S4 methods

[Janko Thyson]

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 <gmbecker at 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.thyson at 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 at 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]]