[
https://issues.apache.org/jira/browse/JENA-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400596#comment-13400596
]
Rob Vesse commented on JENA-270:
--------------------------------
> Expressions really should not return null. The contract is value or eval
> failure. The code is quite protective (FILTER) but it's not the contract.
So it should probably throw an exception instead
> Also see the other use for ARQ_CALL with ?var (args)
> and E_FunctionDynamic -- isn't that neater? Is CALL necessary?
I think CALL is just more explicit in it's intention and less likely to lead to
syntax errors e.g.
Consider COALESCE(?var, (3+4)) - if the user forgets the comma they've suddenly
called COALESCE on ?var(3+4) rather than on ?var and (3+4) if we don't require
CALL
If we do require CALL then that's just a syntax error and the user instantly
knows they have a problem rather than a potentially subtle and hard to diagnose
unexpected query behavior. Yes the example is contrived but hopefully it
highlights my point
Btw how did these things work (if at all) prior to my previous commit,
E_FunctionDynamic just extended E_Call which had no discernible implementation
(or maybe it was just buried higher up in the inheritance tree?) Were my
changes actually necessary or did something higher up already do the work, the
expression evaluation code seems to be particularly convoluted to me with all
these variants on eval() and evalSpecial()?
> Support dynamic function invocation in ARQ
> ------------------------------------------
>
> Key: JENA-270
> URL: https://issues.apache.org/jira/browse/JENA-270
> Project: Apache Jena
> Issue Type: New Feature
> Components: ARQ
> Affects Versions: ARQ 2.9.2
> Reporter: Rob Vesse
> Assignee: Rob Vesse
> Labels: call, dynamic, functions, sparql
> Fix For: ARQ 2.9.2
>
>
> Per my suggestion to the SPARQL Working Group I am proposing a new built in
> CALL() which can be used in SPARQL queries for dynamic function invocation.
> CALL with no argument returns null
> CALL with some arguments evaluates the first argument, sees if the result is
> a URI (if not errors) and if so tries to generate a function from it and
> invoke it with the arguments to that invocation being the remaining arguments
> to CALL
> I have implemented a prototype implementation of this in the ARQ language
> which I have committed to Trunk, others with more knowledge of expression and
> function evaluation in ARQ may have suggestions on how to improve the
> implementation
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
