[
https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532709
]
Daniel John Debrunner commented on DERBY-3069:
----------------------------------------------
Thanks Rick, I'm still not sure that varargs should be resolved to when using
PARAMETER STYLE JAVA for two reasons, but it's better to discuss that with a
concrete detailed proposal, which we are heading towards. The two reasons I see
for not supporting it are:
A) It's non standard, an application using this would fail to run on a database
following the standard, thus breaking Derby's charter.
B) It doesn't provide much benefit, it's forcing a varargs method on a calling
sequence that does not have variable numbers of arguments. SQL routines have
fixed number of arguments. An application can always provide a wrapper method
for a SQL routine that calls the varargs method.
Having said that, here's some feedback on the latest comment.
1) looks reasonable.
2) What you describe does not match how varargs work in Java today. Not saying
that's good or bad, just pointing it out.
v1(new String[1]) will resolve to a method v1(String ...)
Will it be confusing if Derby's resolution to varargs methods does not match
Java semantics?
I also wonder if there's a bug (before any of your changes) where an
INOUT/OUT parameter would incorrectly resolve to a varargs method.
3) Maybe it's just the non-standard nature that makes me think DYNAMIC RESULT
SETS should not resolve to varargs. I can an argument that allowing resolution
to varargs methods that form part of some external library, like J2SE
libraries, JavaMail etc. But no library is going to have method that is
suitable for dynamic result sets, thus any method for dynamic result sets is
going to be specific for that application, so what's the benefit of varargs?
Within the implementation of such a method, does the use of varargs make the
code easier to understand?
customerList[0] = ps.executeQuery(); // non-varargs allows the
variables holding the ResultSet to be specifically named
drs[2][0] = ps.executeQuery(); // varargs, single name for the variable
used to return result sets (or additional code to create local variables)
One other issue here is how big an array should Derby pass into the varargs
method? Is it as simple as the dynamic result set count? I don't think that's
how the non-varargs method works, I think it can resolve to a method (as per
spec) with any number of ResultSet[] parameters. Ie. with a maximum of three
dynamic result sets the method may have holders for six ResultSets, but only
return three, or could return five with two closed.
DYNAMIC RESULT SETS is a variable number of ResultSets on the return from the
method, not the input to the method, thus I don't think it really fits the Java
varargs paradigm.
> Derby does not resolve functions bound to methods with varargs.
> ---------------------------------------------------------------
>
> Key: DERBY-3069
> URL: https://issues.apache.org/jira/browse/DERBY-3069
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.1.4
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-3069-01-varargs-aa.diff,
> derby-3069-01-varargs-ab.diff, z.java, z.sql
>
>
> Varargs were added in Java 5. It would be nice if Derby let you invoke a
> function bound to a method with a variable length argument list. The
> Reference Guide states a small number of restrictions for methods which can
> be invoked as Derby functions: They must be public, static, and not have
> arguments which are long datatypes. I see no reason that Derby shouldn't be
> able to resolve and invoke functions which are bound to methods which don't
> suffer these limitations but which have variable argument lists.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
