-
Notifications
You must be signed in to change notification settings - Fork 7
Feature/auto casting function arguments #103
Feature/auto casting function arguments #103
Conversation
Pull Request Test Coverage Report for Build 1138484875
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the size of this PR, I'm a bit scared of the lack of tests related to this.
We did indeed have tests already that will now cover part of this implementation, but looking at the coveralls output, it seems like coverage is not complete.
Therefore, I would recommend to add more detailed unit tests to the parts of the code you touched. Should be straightforward to do, now that this code is still fresh.
Do you think about changing the test directory structure at the same time? Like talked about in #34 ? So we can create a dir for unit tests as well? |
Oh, I thought we did that one already 😅 I think that's quite urgent, yes. But I would do it in a separate PR. |
I can review the PR this afternoon. I think changing the test folder structure can be done & and merged quickly. Then this PR can be rebased on it (since it will be a significant one, and I do really propose fixing everything mentioned in #102 at once here, it's too closely related). We should indeed strive to not decrease test coverage here, but everything should be able to be tested in theory with some entries in a |
…implemented things
e3bc73f
to
8c8e69c
Compare
lib/functions/OverloadTree.ts
Outdated
if (argumentType === TypeURL.XSD_STRING) { | ||
this.addPromotedOverload(TypeURL.XSD_ANY_URI, func, arg => string(arg.str()), _argumentTypes); | ||
} | ||
this.subTrees[argumentType]._addOverload(argumentTypes, func); | ||
if (argumentType === TypeURL.XSD_FLOAT) { | ||
this.addPromotedOverload(TypeURL.XSD_DOUBLE, func, arg => | ||
number((<E.NumericLiteral>arg).typedValue, TypeURL.XSD_DOUBLE), _argumentTypes); | ||
} | ||
if (argumentType === TypeURL.XSD_DECIMAL) { | ||
this.addPromotedOverload(TypeURL.XSD_FLOAT, func, arg => | ||
number((<E.NumericLiteral>arg).typedValue, TypeURL.XSD_FLOAT), _argumentTypes); | ||
this.addPromotedOverload(TypeURL.XSD_DOUBLE, func, arg => | ||
number((<E.NumericLiteral>arg).typedValue, TypeURL.XSD_DOUBLE), _argumentTypes); | ||
} | ||
} | ||
|
||
private addPromotedOverload(typeToPromote: ArgumentType, func: E.SimpleApplication, | ||
conversionFunction: (arg: E.TermExpression) => E.TermExpression, argumentTypes: ArgumentType[]): void { | ||
if (!this.subTrees[typeToPromote]) { | ||
this.subTrees[typeToPromote] = new OverloadTree(this.depth + 1); | ||
} | ||
this.subTrees[typeToPromote]._addOverload(argumentTypes, args => func([ | ||
...args.slice(0, this.depth), | ||
conversionFunction(args[this.depth]), | ||
...args.slice(this.depth + 1, args.length), | ||
])); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code should allow type promotion as talked about in https://www.w3.org/TR/xpath-31/#promotion . At least, how I understand it. If this is wrong please let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first glance it looks like it could work.
But we'll now for certain once we have tests covering these cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I will add the scheme first and then start writing the tests. With 'wrong' I meant the interpretation of 'promotion'. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A special thing to consider here is that subtype substitution and type promotion can work at the same time. There certainly should be tests for that, as I'm not sure the code handles this like it is (but it's also likely that I'm just missing something).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pretty sure this wouldn't be a problem since promotion is always from a non super type. To another type. And of course like it is now, having a restriction of anyURI provided to a function expecting an xsd_string, the restriction will be substituted to anyUri and will then be promoted to xsd_string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still convinced we can't really test this. So unless someone can give an example on when this could create a problem I consider this to be done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some documentation so people don't break the system and also a test that first performs substitution and that promotion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice work, very important, and cleans things up nicely.
I also think we we can make it a bit cleaner still: see comments and suggested changes.
When merging this PR we should also open 2 new issues.
|
If we wish to implement https://www.w3.org/TR/xpath-31/#promotion completely, we should make sure we cast the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This stuff wasn't trivial, so really good work!
Before we merge, can you again double-check if all tests (unit, integration, spec, ...) still pass in Comunica?
Could you also list in the main description of this PR, what issues can be closed?
I'll wait a bit for merging until @wschella gives his 👍
Thank you!
I checked the overal tests and ran test, integration and spec in the actor-init-sarql package. All tests succeeded. I will add the closing issues. |
@wschella Merged this one already. Feel free to open issues in case you still see issues with this. |
This pull request aims to provide an implementation on auto casting functions as talked about in #102 .
This pull request should NOT be merged before the scheme talked about in #102 is added.
There are a few questions to be answered before merging this PR too, those questions should be marked with a
TODO
.Edit:
We can close a few issues with this PR: #13, #94 and #103.
When merging we open issues about: cast decimal so we can close #12 , questions surrounding
arithmeticWidening
, revision of #103 (comment) (I think this issue is mainly for @wschella) and an issue surrounding caching and open world types.The PR also makes implementation of #87 a lot easier.