View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004423 | 10000-003: Address Space | Spec | public | 2018-10-10 06:02 | 2021-09-07 16:12 |
Reporter | Matthias Damm | Assigned To | Jeff Harding | ||
Priority | normal | Severity | feature | Reproducibility | have not tried |
Status | assigned | Resolution | open | ||
Summary | 0004423: We need a indication of a sealed type | ||||
Description | We have different types e.g. PropertyType where we define that no subtypes are allowed. We have currently no way to indicate this in the information model. Can be done with additional well defined property. Attribute on type nodes is another option but most types will not have this flag set. | ||||
Tags | No tags attached. | ||||
Commit Version | |||||
Fix Due Date | |||||
related to | 0004421 | closed | Jeff Harding | Handling of StructureFields with abstract DataType |
related to | 0004422 | closed | Jeff Harding | Indication if a subtype is allowed as value |
related to | 0005909 | acknowledged | Limitation on subtyping for VariableTypes |
|
PropertyTypes are all sealed by definition. ObjectTypes and VariableTypes are never sealed by definition. Are you asking that Object and Variable Types be defined that can be sealed? |
|
The PropertyTypes may be sealed by definition but this is only defined through text in the specification, not through a machine readable information. I am asking for a general feature to indicate that a type is sealed. If we have this feature, we should use it also for the PropertyType. |
|
A "nice request". But IF the intention would be to be backwards/forwards-compatible, it is close to impossible to retrospectively add this to any type. The PropertyType might be the only possible one where this could be marked (like... if I would nitpick, I would need to very carefully check would a theoretical subtype of PropertyType be allowed; probably not). No other existing type could "ever" be sealed, as there could be already existing subtypes, which this change would break. Like, it might be nice to have, but this would have been something that would had to be in the very first release. Or alternatively this can only apply to new types. But then, IF there IS an old type (that I missed) that is "effectively sealed", it would mean that still cannot be marked as such, and then there would be a rule for all other (new types). Thus, a person reading a future spec version would probably make an assumption that that old type is not sealed, when it practice it would be. |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-10-10 06:02 | Matthias Damm | New Issue | |
2018-10-10 06:02 | Matthias Damm | Relationship added | related to 0004421 |
2018-10-10 06:02 | Matthias Damm | Relationship added | related to 0004422 |
2018-10-23 15:15 | Jim Luth | Note Added: 0009488 | |
2018-10-23 15:15 | Jim Luth | Status | new => feedback |
2020-09-01 15:37 | Jim Luth | Relationship added | related to 0005909 |
2021-03-22 09:21 | Matthias Damm | Note Added: 0014051 | |
2021-03-22 09:21 | Matthias Damm | Status | feedback => new |
2021-04-19 05:48 | BjarneBostrom | Note Added: 0014226 | |
2021-09-07 16:12 | Jim Luth | Assigned To | => Jeff Harding |
2021-09-07 16:12 | Jim Luth | Status | new => assigned |