[
https://issues.apache.org/jira/browse/POLYGENE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020387#comment-16020387
]
Niclas Hedhman edited comment on POLYGENE-257 at 5/22/17 11:26 PM:
-------------------------------------------------------------------
My response to that, effectively saying; Let;s not make large change;
Very good analysis, Paul!
And you are right about the difference between "Module Default" and
"Fallback" differentiation... And what matters now is the way to implement
it. I am not convinced that a default layer is the way to go, although it
seems to be the most easy way to implement it. As a start, I have no
recollection that defined semantics of multiple reachable layers are
anything but "Ambiguous Type". In Visibility.layer, multiple visible
Composites in same layer would result AmbiguousTypeException, and I suspect
that currently that is also the case if found in multiple layers. And for
your approach to work, that would need to be changed to some type of
ordering/priority of layers, or special handling of the polygene-runtime
layer. Neither seems tempting to me right now (before coffee). That change
is also non-reversible in a compatible manner...
What other choices are there?
We could remove the said default types, and instead do the equivalent in
AbstractPolygeneTest (maybe one of the super classes), where it is really
convenient and doesn't impact production code. That would be the quickest
route for a 3.0 and keep the door open for compatible changes in 3.1
We could introduce something like;
{code:java}
module.asFallbackModule().visibleIn( Visibility.application);
{code}
where the semantics are; If no type is found in layer, check the default
module of the layer. If no type found in underlying layers, check default
modules in those underlying layers.
But then again, WHY? Why have two priority levels in TypeLookUp? Why not
have N levels of priority? And that question to me sounds like a slippery
slope, and I would prefer to not go there.
So, right now (half way through coffee cup), I don't think we need anything
conceptually new, just
1. Remove IdentityGenerator and Serialization from defaultAssemblers
2. Change AbstractPolygeneTest to add those by default.
was (Author: niclas):
My response to that, effectively saying; Let;s not make large change;
Very good analysis, Paul!
And you are right about the difference between "Module Default" and
"Fallback" differentiation... And what matters now is the way to implement
it. I am not convinced that a default layer is the way to go, although it
seems to be the most easy way to implement it. As a start, I have no
recollection that defined semantics of multiple reachable layers are
anything but "Ambiguous Type". In Visibility.layer, multiple visible
Composites in same layer would result AmbiguousTypeException, and I suspect
that currently that is also the case if found in multiple layers. And for
your approach to work, that would need to be changed to some type of
ordering/priority of layers, or special handling of the polygene-runtime
layer. Neither seems tempting to me right now (before coffee). That change
is also non-reversible in a compatible manner...
What other choices are there?
We could remove the said default types, and instead do the equivalent in
AbstractPolygeneTest (maybe one of the super classes), where it is really
convenient and doesn't impact production code. That would be the quickest
route for a 3.0 and keep the door open for compatible changes in 3.1
We could introduce something like;
module.asFallbackModule().visibleIn( Visibility.application);
where the semantics are; If no type is found in layer, check the default
module of the layer. If no type found in underlying layers, check default
modules in those underlying layers.
But then again, WHY? Why have two priority levels in TypeLookUp? Why not
have N levels of priority? And that question to me sounds like a slippery
slope, and I would prefer to not go there.
So, right now (half way through coffee cup), I don't think we need anything
conceptually new, just
1. Remove IdentityGenerator and Serialization from defaultAssemblers
2. Change AbstractPolygeneTest to add those by default.
> Custom IdentityGenerator or Serialization hidden by default assemblers
> ----------------------------------------------------------------------
>
> Key: POLYGENE-257
> URL: https://issues.apache.org/jira/browse/POLYGENE-257
> Project: Polygene
> Issue Type: Bug
> Reporter: Paul Merlin
> Assignee: Paul Merlin
> Fix For: 3.0.0
>
>
> See
> https://lists.apache.org/thread.html/9b28a67e75cb8952202d0b0b029de53fc19257b733907408ba20ccde@%3Cdev.polygene.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
