[
https://issues.apache.org/jira/browse/ISIS-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Huber reassigned ISIS-2553:
--------------------------------
Assignee: Andi Huber
> Rationalize value types representing the metamodel, promote to applib if
> possible.
> ----------------------------------------------------------------------------------
>
> Key: ISIS-2553
> URL: https://issues.apache.org/jira/browse/ISIS-2553
> Project: Isis
> Issue Type: Improvement
> Reporter: Daniel Keir Haywood
> Assignee: Andi Huber
> Priority: Minor
> Fix For: 2.0.0-M6
>
>
> 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:
> # {{Identifier }}(AppLib): identifies an application feature, that is a type
> (class) or a type's member (action, property or collection)
> # 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
> # {{ObjectSpecId}}: (internal) class that wraps the logical name (String) of
> the corresponding type (aka *object-type*)
> # {{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-NAME, where the member part (as I
> understand it) for actions only is that action's name with its parameter list
> omitted.
>
> 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: #
> ObjectSpecId: immutable, serializable
> # 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
