- From: Christian Grün <cg@basex.org>
- Date: Sat, 5 Dec 2020 10:34:42 +0100
- To: Michael Kay <mike@saxonica.com>
- Cc: Christian Grün <cg@basex.org>, Dimitre Novatchev <dnovatchev@gmail.com>, Christophe Marchand <cmarchand@oxiane.com>, public-xslt-40@w3.org
> If we're going to have a modifier argument that changes the behaviour then it should be a map, not a string, to make it extensible. But even then, I don't like having a modifier argument that changes the essence of what the function does quite so fundamentally.
I also regarded fn:slice to be a filter expression (as it returns
items of a sequence that match certain conditions). But I see your
point.
I think it’s too much of a commitment to introduce four separate
functions that do pretty much the same. Maybe it’s sufficient in most
cases to use the new fn:index-where function:
let $s := 1 to 10
let $i := index-where($s, function($i) { $i = 5 }) => head()
return (
subsequence($s, 1, $i - 1) (: items-before :),
subsequence($s, 1, $i) (: items-until :),
subsequence($s, $i) (: items-from :),
subsequence($s, $i + 1) (: items-after :)
subsequence($s, $i, 1) (: item-at :)
)
It’s surely not as compact as it could be. On the other hand,
returning subsequences based on a functional predicate is not
something that’s done all the time.
Looking at other contexts may help. In many JavaScript applications,
90% of array processing is done via map, filter and indexOf (or, more
recently, find/findIndex), and it seems to work pretty fine. Dedicated
functions for processing subsequences before/after a specific index
might be nice additions, but I wouldn’t necessarily expect them as
language core functions.
Received on Saturday, 5 December 2020 09:35:07 UTC