View Issue Details

IDProjectCategoryView StatusLast Update
000442310000-003: Address SpaceSpecpublic2021-09-07 16:12
ReporterMatthias Damm Assigned ToJeff Harding  
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status assignedResolutionopen 
Summary0004423: 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.

TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

related to 0004421 closedJeff Harding Handling of StructureFields with abstract DataType 
related to 0004422 closedJeff Harding Indication if a subtype is allowed as value 
related to 0005909 acknowledged Limitation on subtyping for VariableTypes 

Activities

Jim Luth

2018-10-23 15:15

administrator   ~0009488

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?

Matthias Damm

2021-03-22 09:21

developer   ~0014051

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.

BjarneBostrom

2021-04-19 05:48

reporter   ~0014226

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.

Issue History

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