W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2014

[Bug 24726] map:new() and map:merge()

From: <bugzilla@jessica.w3.org>
Date: Wed, 30 Apr 2014 14:32:32 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-24726-523-YJpEnZxJta@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24726

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

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

--- Comment #6 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I agree to renaming map:merge. Also, allowing map{} makes sense, but it doesn't
require a change, it is already allowed:

MapExpr ::= "map{" (KeyExpr ":" ValueExpr ("," KeyExpr ":" ValueExpr )*)? "}"

I would prefer to keep map:entry (or perhaps map:item) as the equivalent
counterpart of xsl:map-entry (or xsl:map-item).

Note also that we used to have map:put, but don't have it anymore.

Furthermore, it strikes me as odd that map:put would _not_ throw an error if
the item already existed. I would like to argue, in line with existing
maps/dictionaries/hashsets in other programming languages, that adding an item
that already exists is not allowed. We could consider both a map:put and
map:set, where the latter overrides an existing entry, or adds it if it doesn't
exist, and the former (map:put) raises an error if an item exists. Instead of
map:put, perhaps map:add is better.

To summarize, I would like:
1) map:add (error if exists)
2) map:put/set (no error if exists, overwrites)
3) map:merge (as per MK's proposal)
4) map{} (as per MK's proposal)
5) map:entry (retain it)
6) remove map:new

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 30 April 2014 14:32:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:46 UTC