db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3069) Derby does not resolve functions bound to methods with varargs.
Date Fri, 05 Oct 2007 16:42:50 GMT

    [ 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.


Mime
View raw message