[
https://issues.apache.org/jira/browse/ISIS-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Huber updated ISIS-2553:
-----------------------------
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:
# {{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.
was:
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.
> 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)
