[
https://issues.apache.org/jira/browse/ISIS-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Keir Haywood 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-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
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
> 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
> 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
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
