Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove duplication of ResourceType strings and enums #3289

Closed
lmsurpre opened this issue Feb 7, 2022 · 1 comment
Closed

Remove duplication of ResourceType strings and enums #3289

lmsurpre opened this issue Feb 7, 2022 · 1 comment
Assignees
@lmsurpre
Labels
enhancement New feature or request r4b technical debt

Comments

@lmsurpre
Copy link
Member

lmsurpre commented Feb 7, 2022

Is your feature request related to a problem? Please describe.
Because of the way we generate code subtypes from code elements with a required binding, fhir-model in 4.x has two code subtype classes that are basically identical:

  • ResourceType
  • FHIRResourceType

Because working with resource types is so common in the codebase, and having an enum of all resource types is handy, we have a lot of places that use the underlying Value enums from these two classes (ResourceType.Value and FHIRResourceType.Value).

For #3268 I wanted to introduce a new ResourceType enum that could be used from fhir-config (and preferably without the complexity overhead of the existing ones) and so I introduce a new ResourceTypeName enum with almost the same content.

Describe the solution you'd like

  1. Core, ubiquitous enum constants for each resource type in the spec.
  2. A single code subtype that wraps this enum for use in the model.

Describe alternatives you've considered
Consolidate ResourceType and FHIRResourceType but keep the resulting class in fhir-model and do not have a separate enum for ResourceType in fhir-core.

Acceptance Criteria

  1. GIVEN [a precondition]
    AND [another precondition]
    WHEN [test step]
    AND [test step]
    THEN [verification step]
    AND [verification step]

Additional context
@lmsurpre lmsurpre added enhancement New feature or request technical debt labels Feb 7, 2022
lmsurpre added a commit that referenced this issue Feb 7, 2022
@lmsurpre
issue #3289 - ResourceType and ResourceTypeCode
e7218a3 
1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Feb 7, 2022
@lmsurpre
issue #3289 - ResourceType and ResourceTypeCode
a7bac14 
1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Feb 7, 2022
@lmsurpre
issue #3289 - ResourceType and ResourceTypeCode
8ca49ae 
1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Feb 7, 2022
@lmsurpre
issue #3289 - ResourceType and ResourceTypeCode
0ee96e3 
1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Feb 7, 2022
@lmsurpre
issue #3289 - ResourceType and ResourceTypeCode
f96c810 
1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Feb 9, 2022
@lmsurpre
issue #3289 - rationalize ResourceType and ResourceTypeCode (#3290)
c0a40cb 
* issue #3289 - ResourceType and ResourceTypeCode

1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* Favor ResourceType over ResourceTypeCode when not in the model

Standardize on ResourceType constants instead of ResourceTypeCode
constants.
The main difference is that ResourceTypeCode extends Code (which is an
Element) and so it can have an optional id and extensions.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* fixup copyrights

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* update copyright on the rest of the generated classes

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Feb 9, 2022
@lmsurpre
issue #3289 - update ExamplesGenerator for ResourceTypeCode case
35bd719 
Because it breaks from our normal pattern, I had to add a special case
to handle this one.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Feb 15, 2022
@lmsurpre
issue #3289 - rationalize ResourceType and ResourceTypeCode (#3290)
ef5c270 
* issue #3289 - ResourceType and ResourceTypeCode

1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* Favor ResourceType over ResourceTypeCode when not in the model

Standardize on ResourceType constants instead of ResourceTypeCode
constants.
The main difference is that ResourceTypeCode extends Code (which is an
Element) and so it can have an optional id and extensions.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* fixup copyrights

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* update copyright on the rest of the generated classes

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Feb 16, 2022
@lmsurpre
issue #3289 - rationalize ResourceType and ResourceTypeCode (#3290)
2dd380f 
* issue #3289 - ResourceType and ResourceTypeCode

1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* Favor ResourceType over ResourceTypeCode when not in the model

Standardize on ResourceType constants instead of ResourceTypeCode
constants.
The main difference is that ResourceTypeCode extends Code (which is an
Element) and so it can have an optional id and extensions.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* fixup copyrights

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* update copyright on the rest of the generated classes

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Feb 16, 2022
@lmsurpre
issue #3289 - rationalize ResourceType and ResourceTypeCode (#3290)
5f3e545 
* issue #3289 - ResourceType and ResourceTypeCode

1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* Favor ResourceType over ResourceTypeCode when not in the model

Standardize on ResourceType constants instead of ResourceTypeCode
constants.
The main difference is that ResourceTypeCode extends Code (which is an
Element) and so it can have an optional id and extensions.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* fixup copyrights

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* update copyright on the rest of the generated classes

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Mar 9, 2022
@lmsurpre
issue #3289 - rationalize ResourceType and ResourceTypeCode (#3290)
56cfd77 
* issue #3289 - ResourceType and ResourceTypeCode

1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* Favor ResourceType over ResourceTypeCode when not in the model

Standardize on ResourceType constants instead of ResourceTypeCode
constants.
The main difference is that ResourceTypeCode extends Code (which is an
Element) and so it can have an optional id and extensions.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* fixup copyrights

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* update copyright on the rest of the generated classes

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Mar 9, 2022
@lmsurpre
issue #3289 - rationalize ResourceType and ResourceTypeCode (#3290)
91a5f98 
* issue #3289 - ResourceType and ResourceTypeCode

1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* Favor ResourceType over ResourceTypeCode when not in the model

Standardize on ResourceType constants instead of ResourceTypeCode
constants.
The main difference is that ResourceTypeCode extends Code (which is an
Element) and so it can have an optional id and extensions.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* fixup copyrights

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* update copyright on the rest of the generated classes

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
@lmsurpre lmsurpre added the r4b label Mar 29, 2022
@lmsurpre lmsurpre self-assigned this Mar 29, 2022
lmsurpre added a commit that referenced this issue Apr 8, 2022
@lmsurpre
issue #3289 - rationalize ResourceType and ResourceTypeCode (#3290)
1e0d4b9 
* issue #3289 - ResourceType and ResourceTypeCode

1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* Favor ResourceType over ResourceTypeCode when not in the model

Standardize on ResourceType constants instead of ResourceTypeCode
constants.
The main difference is that ResourceTypeCode extends Code (which is an
Element) and so it can have an optional id and extensions.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* fixup copyrights

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* update copyright on the rest of the generated classes

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Apr 22, 2022
@lmsurpre
issue #3289 - rationalize ResourceType and ResourceTypeCode (#3290)
0c0e378 
* issue #3289 - ResourceType and ResourceTypeCode

1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* Favor ResourceType over ResourceTypeCode when not in the model

Standardize on ResourceType constants instead of ResourceTypeCode
constants.
The main difference is that ResourceTypeCode extends Code (which is an
Element) and so it can have an optional id and extensions.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* fixup copyrights

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* update copyright on the rest of the generated classes

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue May 12, 2022
@lmsurpre
issue #3289 - rationalize ResourceType and ResourceTypeCode (#3290)
5b03a77 
* issue #3289 - ResourceType and ResourceTypeCode

1. Update the CodeGenerator to combine the ResourceType and
FHIRResourceType code subtypes into a single new code subtype named
`ResourceTypeCode`
2. Rename the ResourceTypeName enum in fhir-core to ResourceType, move
the `from(String)` method there, and update ResourceTypeCode to use this
enum instead of duplicating the values in a nested class
3. Update all uses of ResourceType.Value and FHIRResourceType.Value to
use the new ResourceType enum instead

The result is
1. a simple enum we can use for ResourceType constants throughout the
codebase; and
2. a single code subtype that builds on this enum for when its used
within the fhir model

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* Favor ResourceType over ResourceTypeCode when not in the model

Standardize on ResourceType constants instead of ResourceTypeCode
constants.
The main difference is that ResourceTypeCode extends Code (which is an
Element) and so it can have an optional id and extensions.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* fixup copyrights

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>

* update copyright on the rest of the generated classes

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
@lmsurpre
Copy link
Member Author

I confirm that the ResourceType and FHIRResourceType code subtypes have been replaced with a unified Code subtype ResourceTypeCode and this code subtype uses the ResourceType enum from fhir-core for its values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lmsurpre lmsurpre

Labels
enhancement New feature or request r4b technical debt
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@lmsurpre