Re: Polyfills

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:30:59 UTC