[
https://issues.apache.org/jira/browse/ISIS-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293358#comment-17293358
]
ASF subversion and git services commented on ISIS-2553:
-------------------------------------------------------
Commit ffea1c641e7e14940342dcc8135c49fa209bf746 in isis's branch
refs/heads/ISIS-2553_rational.id from Andi Huber
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=ffea1c6 ]
ISIS-2553: using LogicalType instead of ObjectSpecId (2nd iteration)
> 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-M5
>
>
> 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, 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:
> # 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)
