-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1725b Further elaboration of duplicates handling in maps #1740
base: master
Are you sure you want to change the base?
1725b Further elaboration of duplicates handling in maps #1740
Conversation
As discussed on the mailing list, the decision to use the old or the new key should be made implementation-dependent again, as it had originally been proposed in #1727 (sorry for the additional work). To speak in examples, it will be up to the processor to return map:build((1, 1e0), fn { . }, fn { () }),
map:merge(({ 1: () }, { 1e0: () })),
map:put({ 1: () }, 1e0, ()) |
Preliminary feedback (from a tester): Great to be able to use a function for map:merge(
({ 1: 2 }, { 1: 3 }),
'duplicates': op('*')
) …as it is not easy to distinguish between them. |
I hope my commits to the test suite to accept both the old and the new key in updated map entries were not too hasty. |
I have combined the "duplicates" and "combine" options - a great improvement, thanks for the suggestion. I haven't yet implemented the change to make the choice of keys implementation-dependent, I felt this might need more discussion. In particular, do you want this to apply to |
Definitely yes. In mutable maps, the key serves just for lookup. It would be rather unorthodox to change the key of a map whenever a map entry is updated, and I have never quite understood why it was defined that way for From the (secondary) implementation perspective, I have implemented all variants, and updating only the key would be the most efficient solution as it does not change the key order. |
Further updates:
Reinstated the "tests needed" label since XSLT tests need to be updated with these latest changes. |
The XPath Data Model rules may still need to be tweaked to reflect this freedom. It currently says:
|
39fa65b
to
74e5b03
Compare
74e5b03
to
fada146
Compare
Actions QT4CG-107-02 and QT4CG-107-03.
The three functions map:build, map:of-pairs, and map:merge now all have the same options parameters, and avoid duplication in the specification. The xsl:map instruction is defined by reference to map:merge.
Although the action suggested specifying these functions to use the first key from a set of duplicates, I found this was not possible because of the way map:put is defined. They therefore use the last key from the set of duplicates.
Fix #1725