W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2016

[Bug 29080] array:members

From: <bugzilla@jessica.w3.org>
Date: Fri, 10 Jun 2016 09:54:43 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29080-523-MgBQDnP9Er@http.www.w3.org/Bugs/Public/>

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

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

--- Comment #3 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
(In reply to Michael Kay from comment #1)
> Alternatively (1), an extension to FLWOR expressions that binds a variable
> to each member in turn, as a sequence:
> let $my-array := [(1,2,3), (4,5)]
> for member $m in $my-array return count($m)
> returns (3,2)
I find this interesting and a welcome addition (I'm not quite sure I understand
your 2nd proposal with lambda-expressions). If this is added, I suggest to make
it orthogonal with maps, as looping though a map is just as useful as looping
through an array (apart from the undefined order).

(In reply to Christian Gruen from comment #2)
> A map:values function would be another nice addition, also to have some 
> analogy, but it may not be that pressing.
We tried, back in the day that maps were only a feature of XSLT 3.0. The
problem is with:

let $m := map {'a' : (1,2,3), 'b' : (2,3,4)},
    $v := map:values($m)
return $v[2]

You might expect the second *value* to be returned (i.e., (2,3,4) or (1,2,3)),
but the sequences would collapse. Instead you would get 2, or 3, depending on
how the order of the map is. Furthermore, if the map is copied, the internal
order may change, leading to the same code returning a different value the next
time around.

While I believe map:values() to be a worthwhile addition, even if only to
inspect its contents, this was one of the main reasons it was dropped (though
we maintain it as an extension function in Exselt).

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 10 June 2016 09:54:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:00 UTC