W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2016

[Bug 29723] [FO31] map:merge

From: <bugzilla@jessica.w3.org>
Date: Wed, 20 Jul 2016 13:42:44 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29723-523-GuKghHXgA4@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29723

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #4 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
> unspecified     If duplicate keys are present, the effect is 
> implementation-defined; the implementation may choose one of the above 
> strategies for handling duplicates, or may choose some other strategy.
I would like to suggest that "unspecified" may not act as "combine" or
"reject", because that results in a functional and too unpredictable
difference. It should act as a "use-first", "use-last" or "use-either", in
other words, the only unpredictability of "unspecified" is whether the LH-value
or the RH-value of any given key is used.

If we wouldn't do this, a user cannot know whether he gets a combined sequence
for a given key, or whether he should add a try/catch.

This then also resolves another use-case: if the user knows that duplicate keys
exist, but with the same or exchangeable value, "unspecified" would become the
optimal strategy, where the implementer can choose either value and can
short-circuit evaluation, but will not error, or combine.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 20 July 2016 13:42:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:01 UTC