[
https://issues.apache.org/jira/browse/CONFIGURATION-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095601#comment-18095601
]
Gary D. Gregory commented on CONFIGURATION-857:
-----------------------------------------------
All good questions [~mgalbis]
Since the behavior for most of this code has been around for a long time, I
usually err on the side of documenting the current behavior. That said, there
are always bugs lurking around. Needs more research... Anyone?
> Clarify flatten() behavior for duplicate scalar values and descendant
> branches with back-references
> ---------------------------------------------------------------------------------------------------
>
> Key: CONFIGURATION-857
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-857
> Project: Commons Configuration
> Issue Type: Bug
> Affects Versions: 2.15.1
> Reporter: Maria Galbis
> Priority: Major
>
> This issue is related to:
> - CONFIGURATION-841 (cyclical container handling)
> - CONFIGURATION-849 (preserving required duplicate values)
> The common problem is that {{flatten()}} has to handle both:
> - recursive container graphs
> - legitimate duplicate scalar values
> These two concerns are currently difficult to separate, and I am not sure
> what the expected behavior should be.
>
> *1. Duplicate scalar values for non-String simple types*
> At the moment, duplicate String values are preserved, but it is not clear
> whether the same behavior is expected for other simple scalar types.
> *Examples:*
> {code:java}
> - ["a", "b", "a"] -> ["a", "b", "a"]
> - [1, 2, 1] -> [1, 2, 1]
> - [true, false, true] -> [true, false, true]
> - [1.5, 2.5, 1.5] -> [1.5, 2.5, 1.5]{code}
> *Question:*
> Should duplicate scalar values be preserved for all simple types, not only
> String?
>
> *2. Descendant containers with a back-reference to an ancestor*
> If duplicate scalar values are preserved, there is still an open question
> about descendant containers that are distinct by identity, but contain a
> back-reference to an ancestor.
> Consider the following structure:
> {code:java}
> root = [0]
> root.add(root)
> root.add(new ArrayList<>(root))
> root.add(1)
> root.add(new ArrayList<>(root)){code}
> Conceptually, this produces a graph where descendant containers are distinct
> by identity, but some of them still contain a back-reference to an ancestor.
> {code:java}
> - [0, self, copy1, 1, copy2]
> - copy1 = [0, self]
> - copy2 = [0, self, copy1, 1]{code}
> If only cyclic container references are removed, the remaining scalar leaves
> would be:
> {code:java}
> [0, 0, 1, 0, 1]{code}
> If instead any descendant branch containing a back-reference is treated as
> invalid, the result would be:
> {code:java}
> [0, 1]{code}
> *Question:*
> Which behavior is expected for {{{}flatten(){}}}?
> - keep scalar leaves from descendant branches and only prune cyclic ontainer
> references
> - or discard the whole descendant branch once it points back to an ancestor
>
> The important point is that the implementation cannot reliably distinguish a
> copied container from a legitimate distinct container with similar or
> overlapping content, so the expected semantics need to be clarified before
> changing the implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
