[OASIS Issue Tracker] Updated: (ODATA-500) Require function/action overloads to differ by ordered set of parameter types

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/ODATA-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-500:
-----------------------------

       Issue Type: New Feature  (was: Bug)
    Fix Version/s: V5.0_WD01
                       (was: V4.0_ERRATA01)

This would break important use cases: we've removed nullable function parameters, so in order to model nullable query parameters (which we have in our business intelligence systems) we need the following overloads:

1. Query(String CostCenter, String AccountingSystem)
2. Query(String CostCenter) - use the default accounting system
3. Query(String AccountingSystem) - use the default cost center for the authenticated user
4. Query() - use both defaults

2 and 3 would be forbidden by adding this rule.

> Require function/action overloads to differ by ordered set of parameter types
> -----------------------------------------------------------------------------
>
>                 Key: ODATA-500
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-500
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: New Feature
>          Components: OData CSDL
>    Affects Versions: V4.0_CS
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V5.0_WD01
>
>
> [CSDL] does function overload resolution by the unordered set of parameter names. Most languages do function overload resolution according to the ordered set of parameter types.
> Currently, [CSDL] allows two function overloads with different parameter names to have the same types:
> <Function Name="Evaluate" ReturnType="Integer">
>  <Parameter Name="Input" Type="Edm.Integer"/>
> </Function>
> <Function Name="Evaluate" ReturnType="Integer">
>  <Parameter Name="Variable" Type="Edm.Integer"/>
> </Function>
> This doesn't add significant value, could be confusing, and would not be supported in most programming languages.
> It is okay for OData to be more restrictive than conventional programming languages, but having it arbitrarily less restrictive makes it difficult to expose a client side programming model in a conventional language.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira