This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26559 - Maps and Arrays: Analogies
Summary: Maps and Arrays: Analogies
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-12 15:21 UTC by Christian Gruen
Modified: 2014-11-17 09:50 UTC (History)
2 users (show)

See Also:


Attachments

Description Christian Gruen 2014-08-12 15:21:43 UTC
I was asked why some of the new map and array functions have been named so differently although they do similar things, and why there is some redundant functionality. Here are the suggestions we came up with:

* array:size vs. (no map:size anymore): it would be great if "map:size" was readded to the spec; count(map:keys()) is not very intuitive, at least to me, and it feels like a burden to loop through data if you simply want to know the number of entries.

* map:for-each-entry, array:for-each-member: we could simplify the names to map:for-each and array:for-each, because the other functions are not named "array:filter-members" etc. either.

* map:merge vs. array:join: although different things may happen under the hood, they could share the same name. "map:join" sounds like an intelligible alternative to me.

* map:get vs. (no array:get): maybe we can get rid of this function, or (if it is required for some reason) additionally provide "array:get"?

* map:entry: maybe we can give up this one, too?
Comment 1 Michael Kay 2014-08-12 17:00:58 UTC
I think the omission of map:size() from the spec is a mistake, though there is prose that says it was a deliberate decision at some point, I'm pretty sure it was reversed; the current XSLT 3.0 draft has the spec as agreed between the WGs.

Part of the reason for having different names map:for-each-entry, array:for-each-member was that I think we were keeping options open at the time that the functions might end up in the same namespace. I agree there's less logic to it now.

I agree the argument for getting rid of array:get() applies equally to map:get(); the only difference is that different people are involved in the decision, since the map functions are in XSLT 3.0 which has been around for a while and is now at last call.

I agree that the need for map:entry is weaker now that we have map:put. On the XSLT side we've been keen that maps should be usable without new syntax, e.g. as an add-on library to XSLT 2.0 and XPath 2.0, and this creates a requirement for a more complete set of functions than are needed in an XPath 3.1 context - this also affects the need for map:get().
Comment 2 Jonathan Robie 2014-08-12 20:22:53 UTC
(In reply to Christian Gruen from comment #0)
> I was asked why some of the new map and array functions have been named so
> differently although they do similar things, and why there is some redundant
> functionality. Here are the suggestions we came up with:
> 
> * array:size vs. (no map:size anymore): it would be great if "map:size" was
> readded to the spec; count(map:keys()) is not very intuitive, at least to
> me, and it feels like a burden to loop through data if you simply want to
> know the number of entries.

I agree with you and Mike: adding map:size() back would be good.

> * map:for-each-entry, array:for-each-member: we could simplify the names to
> map:for-each and array:for-each, because the other functions are not named
> "array:filter-members" etc. either.

+1

> * map:merge vs. array:join: although different things may happen under the
> hood, they could share the same name. "map:join" sounds like an intelligible
> alternative to me.

Not so sure on this one.  Maybe using merge for both?  Or is there a better name?

> * map:get vs. (no array:get): maybe we can get rid of this function, or (if
> it is required for some reason) additionally provide "array:get"?
> 
> * map:entry: maybe we can give up this one, too?

+1 on killing both.
Comment 3 Jonathan Robie 2014-09-09 16:56:28 UTC
We agreed to:

* add map:size()
* rename map:for-each-entry to map:for-each, array:for-each-member to array:for-each
* add array:get() and keep map:get()

We decided to keep the following distinction, since maps combine without order, and joining arrays is concatenation, analogous to string concatenation

* map:merge vs. array:join

We decided to keep the following because it has long been part of XSLT:

* kill map:entry()

XQuery has agreed to the following change, not yet agreed to by XSLT:

* map:for-each-entry, array:for-each-member
Comment 4 Michael Kay 2014-09-25 20:49:46 UTC
The XSL WG today confirmed its acceptance of the following change:

map:for-each-entry is renamed map:for-each
array:for-each-member is renamed array:for-each

These changes have been applied to the F+O 3.1 and XSLT 3.0 specifications.
Comment 5 Michael Kay 2014-11-17 09:50:22 UTC
For the record, array:get didn't make it into the October WD, and resurfaces as bug #27231. Marking as closed.