Difference between revisions of "Datatypes R2 Issue 9"
| Line 5: | Line 5: | ||
Clarify the semantics of Set, Bag and List to allow proper determination of allowed substitutions as extensions and restrictions. | Clarify the semantics of Set, Bag and List to allow proper determination of allowed substitutions as extensions and restrictions. | ||
At present, it’s not clear which “collection types” can be substituted. | At present, it’s not clear which “collection types” can be substituted. | ||
| − | |||
? backward compatible. None. (May identify some existing specifications as non-compliant) | ? backward compatible. None. (May identify some existing specifications as non-compliant) | ||
| Line 14: | Line 13: | ||
Proposed: | Proposed: | ||
| − | SET<T> restricts BAG<T> | + | |
| − | LIST<T> restricts PLIST<T> (see other proposal) | + | SET<T> restricts BAG<T> |
| − | PLIST<T> extends BAG<T> | + | LIST<T> restricts PLIST<T> (see other proposal) |
| + | PLIST<T> extends BAG<T> | ||
It’d be really helpful if we clarified what the default collection type is for associations too (suggest BAG). Also need to identify how immutability and cardinality apply differently to the collection types than they do to other datatypes. | It’d be really helpful if we clarified what the default collection type is for associations too (suggest BAG). Also need to identify how immutability and cardinality apply differently to the collection types than they do to other datatypes. | ||
| Line 22: | Line 22: | ||
There is no unique hierarchical relationship between those. What is the use case? --[[User:Gschadow|Gschadow]] 01:13, 25 Jun 2006 (CDT) | There is no unique hierarchical relationship between those. What is the use case? --[[User:Gschadow|Gschadow]] 01:13, 25 Jun 2006 (CDT) | ||
| + | BOF: No | ||
| + | |||
| + | Further comments: | ||
| + | * The PLIST proposal was rejected. | ||
| + | * The problem is that substitution is allowed. This does not require any gen/spec relationship | ||
| + | * The semantics are complicated; Even trying to introduce a generic collection ancestor is an exercise in futility. | ||
| − | + | For the reasons outlined above, I think this should be rejected.--[[User:GrahameGrieve|GrahameGrieve]] 10:21, 3 May 2007 (CDT) | |
| + | btw note the the MNM hot topic [[# Datatype Substitution Issues]]. | ||
== Disposition == | == Disposition == | ||
| + | |||
| + | R2 taskforce Vote Record: | ||
| + | Reject: Grahame | ||
| + | Continue Discussion: | ||
== Status == | == Status == | ||
Revision as of 15:21, 3 May 2007
Contents
Data Types Issue 9: Clarify BAG-SET-LIST relationship
Introduction
Clarify the semantics of Set, Bag and List to allow proper determination of allowed substitutions as extensions and restrictions. At present, it’s not clear which “collection types” can be substituted.
? backward compatible. None. (May identify some existing specifications as non-compliant)
MnM
Discussion
Proposed:
SET<T> restricts BAG<T> LIST<T> restricts PLIST<T> (see other proposal) PLIST<T> extends BAG<T>
It’d be really helpful if we clarified what the default collection type is for associations too (suggest BAG). Also need to identify how immutability and cardinality apply differently to the collection types than they do to other datatypes.
There is no unique hierarchical relationship between those. What is the use case? --Gschadow 01:13, 25 Jun 2006 (CDT)
BOF: No
Further comments:
- The PLIST proposal was rejected.
- The problem is that substitution is allowed. This does not require any gen/spec relationship
- The semantics are complicated; Even trying to introduce a generic collection ancestor is an exercise in futility.
For the reasons outlined above, I think this should be rejected.--GrahameGrieve 10:21, 3 May 2007 (CDT)
btw note the the MNM hot topic # Datatype Substitution Issues.
Disposition
R2 taskforce Vote Record:
Reject: Grahame Continue Discussion:
Status
Proposed
Links
Back to Data Types R2 issues
