- From: <bugzilla@jessica.w3.org>
- Date: Mon, 02 Nov 2015 17:11:53 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29251 --- Comment #6 from Abel Braaksma <abel.braaksma@xs4all.nl> --- > * takes one or more functions as arguments, > * returns a function as its result. Perhaps this is simpler? I agree to your (a), which means such processors should implement maps and arrays, not function items. An analogy to streaming comes to mind. I have the feeling that this feature should mean that a "function item" cannot be invoked (absorption). But inspecting whether something is a function item should be allowed, so that both your option (a) and (b1/b2) can co-exist. This can lead to dynamic errors only in the case of map/array-style invocation, where the actual item turns out being a function and not a map. This means that if a processor follows (a), it is possible to do "$f instance of function(*)", it will simply return true for maps and arrays, and false otherwise (it cannot be a function item). Likewise, it should be possible to do function-name($f), where $f can be a map or an array, in which case the name is the empty sequence. Another outcome is not possible (unless a type error). And function-arity($f) will always return 1, or an error. This is then consistent between your (a) and (b), where in the case of (b) those functions SHOULD return something useful, if the function item comes from an external input sequence. Going this way, it will allow users to have <xsl:param name="m-or-a" as="function(*)" />, which can then contain a map or an array. And "function(xs:int) as xs:string" can be a map with int keys or an array. I think this is not too hard to get right (might be even simpler than your original proposal), and even though it marginally differs from XQuery, I think it does so for good reasons (and perhaps XQ31 wants to bring its definition in line with this, if there's some interest). I would prefer not to differentiate between b1 and b2, because it may be inevitable when using a library package that such items at some point "exist". Opting for the inspection, but not absorption rule makes this as painless as possible. It's a bit like C# 4, which supports the async keyword for asynchronous processing. C# 3 users can not use it, but can still call into libraries build with C# 4+ that use the async keyword. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 2 November 2015 17:12:00 UTC