OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


    [ http://tools.oasis-open.org/issues/browse/ODATA-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34531#action_34531 ] 

Ralf Handl edited comment on ODATA-500 at 9/3/13 7:03 PM:
----------------------------------------------------------

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. 

We can only agree to this additional rule if different type definitions based on the same underlying primitive type are allowed, so we could type-define CostCenter and AccountingSystem. 

      was (Author: ralfhandl):
    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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]