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" another enumeration type


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

Ken Baclawski commented on ODATA-849:
-------------------------------------

Summary of the Discussion of Enumeration Extension on 5 November 2015

The discussion quickly focused on two of the possibilities for enumeration extension described in the proposal, the first one and the third one.  There was no support for the second one.

The first possibility is to extend the enumeration by creating a new enumeration, independent of the original enumeration.  This would just be a convenience since the same effect could be achieved by just copying and pasting.

The third possibility in the proposal would create a new base type for the enumeration, called the widening of the enumeration.  This would support substitutability.  So a member of the enumeration would be the same as one of the members of the new base type.

An interesting example is that of German holidays.  There are national holidays, but each state can add its own holidays.  For example, New Year's Day is a national holiday, while the state of Saxony is the only state that celebrates Repentence Day.  If the enumeration for national holidays is NationalHoliday, and the enumeration for Saxony holidays is SaxonyHoliday, then:

1. Using the extends semantics, one has two different New Year's Day holidays, one in NationalHoliday and one in SaxonyHoliday.  This is compatible with programming languages which have no mechanism for extending enumerations.  Using the word "extends" for this process is compatible with the use of this word for containers.  Unfortunately, Java uses "extends" to mean subclass, and that is not compatible with either container extension or enumeration extension.

2. Using the widens semantics, there is only one New Year's Day holiday.  The one in NationalHoliday is the same as the one in SaxonyHoliday.  This is compatible with what one normally thinks of when one is talking about holidays.  The widens semantics is a subclass/superclass relationship.  The only difference is that widening is defining a new superclass (base class) rather than defining a new subclass.  This is the reason for using a different word for the process.  Using "extends" would be confusing because this word is already in use by Java to mean subclass.

A number of issues were raised:

1. Adding a new attribute would cause problems for backward compatibility.  This would be a problem for either case, but only the extends semantics could be negotiated and supported.  It was pointed out that other features would have to be negotiated anyway, so it would not be a big problem to add another negotiated feature.

2. Would one ever use the substitutability supported by the widens semantics?  If it is never used, then it would not be worth adding the feature.  One way to look at this is whether substitutability is ever used for ordinary subclassing.  If one has a subclass Professor of Person, then each Professor object is also a Person object.  If substitutability were not supported in this case, then Albert Einstein as a person would be a different object than Albert Einstein as a professor.  Are there any scenarios where it would matter that there are now two different Albert Einstein objects?

3. Multiple inheritance could be a problem.  Limiting to a single widening of an enumeration is unrealistic.  For the German holidays, there are many German states, and each one would have its own widening.  Indeed, there are some holidays that are observed in several states but not all of them.


> Add possibility for enumeration types to "extend" another enumeration type
> --------------------------------------------------------------------------
>
>                 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: Enum Types
>            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 defined by a different schema. 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. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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