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] (ODATA-849) Add possibility for enumeration types to "extend" other enumerations

    [ https://issues.oasis-open.org/browse/ODATA-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60687#comment-60687 ] 

Mark Stafford commented on ODATA-849:

If I understand the issue correctly, the reason we experience pain when values are added is because we serialize the string, not the underlying value. Were we to serialize the underlying value, enum members could be added without consequence.

Would it be better to allow clients to specify whether they want the string or the integral value of the enum? This would enable "proper" clients like Olingo etc to avoid the breaking change aspect of adding enum members as well as benefit from improved performance. Clients who still want the string value, such as an "unaware" JavaScript client, could continue to naively use the value in UIs, also not caring about the new value.

This seems like a more graceful solution than introducing a new concept, especially one that may be hard to map to certain languages for code generation.

> Add possibility for enumeration types to "extend" other enumerations
> --------------------------------------------------------------------
>                 Key: ODATA-849
>                 URL: https://issues.oasis-open.org/browse/ODATA-849
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: New Feature
>          Components: OData CSDL
>    Affects Versions: V4.0_ERRATA02
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>            Priority: Minor
>             Fix For: V4.01_WD01
> [Alternative to ODATA-494]
> We currently don't have a way for adding values to an enumeration type. This would be helpful for defining custom vocabularies that extend base vocabularies. 
>  However, defining inheritance for enumerations introduces substitutability that is likely to break clients by returning new enumeration values not anticipated by the client (for instance, in a switch statement). 
>  An alternative to inheritance would be to introduce the ability for an enumeration type to *definitionally* extend an existing enumeration type. This is similar to what we do with entity containers, which can extend the definition of an existing container without introducing any substitutability. 
>  We could even use the same "Extends" attribute, rather than "BaseType" which implies inheritance. 
>  
> Activity

This message was sent by Atlassian JIRA

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