Github user felixcheung commented on a diff in the pull request:
https://github.com/apache/spark/pull/14558#discussion_r74974091
--- Diff: R/pkg/R/DataFrame.R ---
@@ -510,9 +510,7 @@ setMethod("registerTempTable",
#'
#' Insert the contents of a SparkDataFrame into a table registered in the
current SparkSession.
#'
-#' @param x A SparkDataFrame
-#' @param tableName A character vector containing the name of the table
--- End diff --
I see.
We typically have
```
setGeneric("foo", function(x, ...) {...}
setMethod("foo", signature(x = "A"), function(x, a, b, moreParameters) {...}
```
In many cases we have setGeneric the fewer number of parameters - whether
it is because it has to match an existing generic or some parameters we don't
put in the signature with type - so we would have a parameter and `...` in the
generic.
I see your point about if the parameter is in the generic then perhaps we
should @param document it there as well.
I think we should try to keep it near the function definition/body though
because
1) that's where the parameter is actually being used and its meaning could
change
2) it would be easier to review - we have a few changes out where the first
parameter does not have a @param (it should help when we turn on check-cran in
Jenkins)
3) many of our functions are like this so if we are to move the @param for
the first parameter to generics.R (if there is `...` there) then there will be
dozens or hundreds of lines changing (eg. bround, contains, subset and many
more)
with the exception where we've talked about the generic applies to multiple
function definitions with different classes and that first parameter could be
in different classes so it needs a central place.
What do you think?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
