- From: <bugzilla@jessica.w3.org>
- Date: Wed, 20 Jul 2016 13:42:44 +0000
- To: public-qt-comments@w3.org
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