[CAUSEWAY-2553] Rationalize value types representing the metamodel, promote to applib if possible.

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Fix Version/s: 2.0.0-M5
• Assignee: Andi Huber
• Reporter: Daniel Keir Haywood
• Created: 01/Mar/21 06:51
• Updated: 07/Mar/21 07:29
• Resolved: 07/Mar/21 07:29

Description

We have some duplication between classes that describe elements of our metamodel.  We also have a legacy of names that relate to physical aspects (eg PACKAGE) whereas internally we are now using logical names (derived from @DomainObject(objectType=), in other words ObjectSpecIdFacet) throughout.  And it would probably be safe to promote all of this to the applib once clean - we currently only expose strings.

Andi's summary of what we have:

1. Identifier (AppLib): identifies an application feature, that is a type (class) or a type's member (action, property or collection)
2. TypeIdentifier  (AppLib): introduced this weekend, to effectively amend the {{Identifier }}with an additional field, that provides the logical name of the type (aka object-type); immutable as much as possible, but allows for lazy evaluation of the logical name, as it requires the meta-model to be populated
3. ObjectSpecId: (internal) class that wraps the logical name (String) of the corresponding type (aka object-type)
4. ApplicationFeatureId: (internal) Similar to Identifier, but splits the logical type name or member name into its parts: PACKAGE, CLASS, MEMBER which with logical name support now need to be interpreted as NAMESPACE, LOGICAL-TYPE-SIMPLE-NAME and MEMBER, where the member part for actions also includes its parameter list.

 

Further discussion:

• Dan - To me, it looks like TypeIdentifier and ObjectSpecId both describe a type (aka ObjectSpecification)
• Andi - correct
• Dan -  Meanwhile Identifier is kind of a superclass that represents either types or `ApplicationFeatureId`s
   
• Dan - And we perhaps should rename from PACKAGE to NAMESPACE, etc, if that's what these now are.
• Andi - Was my first thought today when I woke up, renaming those fields within ApplicationFeatureId.
   

also note why the distinction between ObjectSpecId and TypeIdentifier:

1. ObjectSpecId: immutable, serializable
2. TypeIdentifier: thread-safe lazy initialization, hence not serializable

Further thoughts from Andi:

TypeIdentifier lazily evaluates the logical name, because instances of TypeIdentifier get created as early as the meta-model is in its phase of being built up. So the logical name only gets evaluated and memoized when first needed by any caller. So once memoized, the TypeIdentifier can be made serializable easily. I might just do that, so we are on the safe side here.

Issue Links

• is superceded by: CAUSEWAY-2569 Further rationalize value types representing the metamodel.
• links to: GitHub Pull Request #407
• links to: GitHub Pull Request #409