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

[Bug 29080] array:members

From: <bugzilla@jessica.w3.org>
Date: Tue, 14 Jun 2016 14:23:23 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29080-523-GcQ8rNbUSY@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29080

--- Comment #10 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
(In reply to Josh Spiegel from comment #9)
> Currently this evaluates to:
> 
>   <result><webster>9 5</webster><kirkwood>6</kirkwood></result>
> 
> But under your proposal, it would return:
> 
>   <result><webster>9 5</webster><kirkwood>5 7</kirkwood></result>
> 
> Correct?
> 
> If so, I think a user would find this surprising.
I think this currently evaluates to an error, because, unless I misunderstand
the signature or your code, fn:avg#1 does not take an array as its argument
(which in itself may be considered surprising).

(In reply to Michael Kay from comment #8)
> Please no. The LHS can already be a singleton array or a singleton map
> (indeed, it can be anything) and it currently offers complete orthogonality
> and substitutability. 
I understand your resentment against the proposal, but we have done a similar
thing, for instance, for the new lookup operator, which special cases based on
whether it is an item or an array.

I think that, conversely, the orthogonality and substitutability argument can
also be used in favor of allowing arrays in some places where currently only
sequences are allowed. I.e., in the fn:avg example in comment#9 from Josh.

Some languages (Python, C#) allow any traversable sequences (arrays,
dictionaries, collections, queues) for such functions as looping, iterations,
averaging, concat operators etc. So I don't think the idea itself is very
strange.

Anyway, I thought it was a good idea (in the sense of "an easy solution"), but
it looks like there's a lot more to it than I thought.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 14 June 2016 14:23:27 UTC

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