Re: Polyfills

Yep, works for me:

1) It allows providing an implementation in case there is none (it
fulfils the use case).

2) The complexity of the incantation in order to override an fn:*
function does not really matter, I believe.

Regards,

-- 
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/


On 19 February 2016 at 12:28, Michael Kay wrote:
> Another way of satisfying the requirement would be:
>
> (a) the user must specify a value for override-extension-function
>
> (b) if the specified value is "yes", and the processor has an implementation of the function available, then the processor has the option of rejecting the overriding function (with a static error) because its built-in implementation cannot be overridden.
>
> (And perhaps the attribute should become override-system-function?)
>
> Example:
>
> <xsl:function name="fn:normalize-unicode" _override-system-function="{system-property('xsl:vendor') = 'altova'}">
>   ...
> </xsl:function>
>
> Michael Kay
> Saxonica
>
>
>> On 19 Feb 2016, at 10:21, Florent Georges <fgeorges@fgeorges.org> wrote:
>>
>> Hi,
>>
>> We discussed this briefly earlier this week in Prague, and the
>> consensus was something like: "it is going to be very costly if the
>> user can override any standard function."  The typical example is that
>> an optimisation such as replacing fn:true() with the actually constant
>> value "true" (whatever it is in the implementation) during parsing or
>> compiling would become illegal.  A user could always override it to
>> return false.  Not even mentioning a sequence of nodes.
>>
>> This is all very sensible.  There is one specific case we might want
>> to consider though...
>>
>> I was trying to use the XPath 3.0 function fn:unparsed-text-lines()
>> yesterday on MarkLogic.  But it is not implemented.  And it would have
>> been nice to be able to provide my own.
>>
>> So maybe, if we do not want the user to override existing fn:*
>> functions, we still might consider to allow users to define a function
>> in the fn:* namespace, but *only if it is not a function implemented
>> by the processor*.
>>
>> That would solve the problem of partial standard library
>> implementation, as well as functions defined in the future or outside
>> F&O (note: "new functions" includes indeed "new arities" for an
>> existing function name).  Without sacrificing intensive optimisation
>> in early stages of the static phase.
>>
>> The one issue I see to be solved though: what to do in case the
>> function already exists?  Is it an error or does the processor ignore
>> it?  In XSLT, an error would make sense as we can have use-when to
>> prevent the processor to even see it in case it provides the function.
>> But would be harder to achieve in XQuery, if they ever wanted to adopt
>> the same mechanism.
>>
>> --
>> Florent Georges
>> http://fgeorges.org/
>> http://h2oconsulting.be/
>>
>>
>> On 8 February 2016 at 11:26, Liam R. E. Quin wrote:
>>> On Mon, 2016-02-08 at 08:47 +0000, Michael Kay wrote:
>>>>
>>> [...]
>>>> Because this change does not require any changes to existing
>>>> implementations or stylesheets (it permits such changes but does not
>>>> require them), I see no difficulty with making it during CR.
>>>
>>> +1 -- although it should be tested for.
>>>
>>> Liam
>>

Received on Friday, 19 February 2016 11:43:01 UTC