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] Commented: (ODATA-341) Can we get rid of the optional trailing 'L'/'l' for int64 numbers

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

Ralf Handl commented on ODATA-341:

Correct, also in the contributed starter documents it wasn't optional, and I can't find a Jira ticket to make them optional so that's probably a typo or wrong refactoring, propagating the optionality from the nanInfinity rule to the xxxBody rules.

On the other hand: as we now forbid function overloads that only differ in sub-types within the type families Integer and Float, so I see no situation where we'd have to "disambiguate" identical numeric values according to the representing type.

So I think we can at least get rid of the "d", "f", and "l" suffixes.

I also doubt the usefulness of function overloads for Integer and Float where the Float overload produces different results than the Integer overload for integer numbers.

> Can we get rid of the optional trailing 'L'/'l' for int64 numbers
> -----------------------------------------------------------------
>                 Key: ODATA-341
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-341
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData ABNF Construction Rules
>         Environment: [Proposed]
>            Reporter: Hubert Heijkers
>            Priority: Minor
> According to the ABNF an optional 'L'/'l' character MAY be included. I was asked why this was and failed to give an answer. Dear I ask why we allow this whereas we don't make any distinction that way for the other integer types?We already allow for upscaling to a bigger type, why couldn't any integer number be just specified using its digits full well knowing that if more then 15 digits are required it has to be an int64 number ?

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]