OASIS Open Data Protocol (OData) TCIcon indicating the project type

OASIS Open Data Protocol (OData) TC

Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-341

Can we get rid of the optional trailing 'L'/'l' for int64 numbers

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: V4.0_WD01
    • Fix Version/s: V4.0_WD01
    • Component/s: ABNF
    • Labels:
      None
    • Environment:

      [Applied]

      Description

      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 ?

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          sdrees Stefan Drees (Inactive) added a comment - - edited

          Is there a typo where more should read mere (meaning solely, only?) in: "[...]whereas all the other integer types simply allow for more digits to be returned[...]"?

          Two things from the ABNF:

          1. Let's all remember again, the case insensitive nature of ABNF (i.e. outside the "single quote reservations" of our extended usage):

          int64 = int64Body [ "L" ]
          int64Body = [ sign ] 1*19DIGIT ; numbers in the range from -9223372036854775808 to 9223372036854775807

          the two lines cited from current ABNF (svn revision 231) have a double quote enclosed L which may well be a lowercase letter l.

          2. And also, that this postfix letter (L or l) as it is placed inside square brackets is thus optional.

          Show
          sdrees Stefan Drees (Inactive) added a comment - - edited Is there a typo where more should read mere (meaning solely, only?) in: " [...] whereas all the other integer types simply allow for more digits to be returned [...] "? Two things from the ABNF: 1. Let's all remember again, the case insensitive nature of ABNF (i.e. outside the "single quote reservations" of our extended usage): int64 = int64Body [ "L" ] int64Body = [ sign ] 1*19DIGIT ; numbers in the range from -9223372036854775808 to 9223372036854775807 the two lines cited from current ABNF (svn revision 231) have a double quote enclosed L which may well be a lowercase letter l. 2. And also, that this postfix letter (L or l) as it is placed inside square brackets is thus optional.
          Hide
          Permalink
          hubert.heijkers Hubert Heijkers (Inactive) added a comment -

          Mmm, not sure how I've missed the fact the 'L' is optional. Leaves the question why anybody would add it. I suppose we can close this then with no further action.

          Show
          hubert.heijkers Hubert Heijkers (Inactive) added a comment - Mmm, not sure how I've missed the fact the 'L' is optional. Leaves the question why anybody would add it. I suppose we can close this then with no further action.
          Hide
          Permalink
          hubert.heijkers Hubert Heijkers (Inactive) added a comment -

          Updated the issue after, based on previous comments, realizing the 'L'/'l' is optional.

          Show
          hubert.heijkers Hubert Heijkers (Inactive) added a comment - Updated the issue after, based on previous comments, realizing the 'L'/'l' is optional.
          Hide
          Permalink
          matthew.borges Matthew Borges (Inactive) added a comment -

          In V2 and V3 the "L"/"l", and equivalently the "D"/"d" for doubles, "F"/"f" for floats, and "M"/"m" for decimals was NOT optional.

          Show
          matthew.borges Matthew Borges (Inactive) added a comment - In V2 and V3 the "L"/"l", and equivalently the "D"/"d" for doubles, "F"/"f" for floats, and "M"/"m" for decimals was NOT optional.
          Hide
          Permalink
          ralfhandl Ralf Handl added a comment -

          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.

          Show
          ralfhandl Ralf Handl added a comment - 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.
          Hide
          Permalink
          matthew.borges Matthew Borges (Inactive) added a comment -

          My only concern with removing them fully is backwards compatibility. Making them optional seems to give the best of both worlds.

          Show
          matthew.borges Matthew Borges (Inactive) added a comment - My only concern with removing them fully is backwards compatibility. Making them optional seems to give the best of both worlds.
          Hide
          Permalink
          hubert.heijkers Hubert Heijkers (Inactive) added a comment -

          There doesn't seem to be a reason for having the 'l' or 'L' to indicate we are dealing with a 64-bit integer value. Also we are no longer allowing function overloading within the same type family so it is, presuming it was, no longer required to choose the appropriate override of a function either. The same applies to the 'f'/'F', 'd'/'D' and 'm'/'M' qualifiers indicating single, double and decimal values respectively. The proposal is updated to include the removal of those as well.

          Show
          hubert.heijkers Hubert Heijkers (Inactive) added a comment - There doesn't seem to be a reason for having the 'l' or 'L' to indicate we are dealing with a 64-bit integer value. Also we are no longer allowing function overloading within the same type family so it is, presuming it was, no longer required to choose the appropriate override of a function either. The same applies to the 'f'/'F', 'd'/'D' and 'm'/'M' qualifiers indicating single, double and decimal values respectively. The proposal is updated to include the removal of those as well.

            People

            • Assignee:
              handl Ralf Handl
              Reporter:
              hubert.heijkers Hubert Heijkers (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: