[Bug 26559] New: Maps and Arrays: Analogies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 26559] New: Maps and Arrays: Analogies

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26559

            Bug ID: 26559
           Summary: Maps and Arrays: Analogies
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3.1
          Assignee: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

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?

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 26559] Maps and Arrays: Analogies

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26559

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #1 from Michael Kay <[hidden email]> ---
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().

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 26559] Maps and Arrays: Analogies

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26559

--- Comment #2 from Jonathan Robie <[hidden email]> ---
(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.

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 26559] Maps and Arrays: Analogies

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26559

Jonathan Robie <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |[hidden email]
         Resolution|---                         |FIXED

--- Comment #3 from Jonathan Robie <[hidden email]> ---
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

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 26559] Maps and Arrays: Analogies

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26559

--- Comment #4 from Michael Kay <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the QA Contact for the bug.