Closed jitsedesmet closed 1 year ago
@rubensworks given the implementation in https://github.com/comunica/sparqlee/pull/180 is what you want for Ordering
, I would keep making the regular functions call the regular functions since it is more self-contained.
Also, if we would want to call ordering, we would not want the fall through case as mentioned in a commend I made (and later resolved in favor of this PR)
Also, if we would want to call ordering, we would not want the fall through case as mentioned in https://github.com/comunica/sparqlee/pull/180#discussion_r1257265191
Ok, then we can change that I guess? That's the same reason why I added the strict
parameter on orderTypes
in d1e01c353c9c2ae810cece7ec4ff209ec1a57dd6.
But why would you want this? I feel like this case is way better? You have all the logic of the regularfunctions in this one file?
Why would you want to go: RegularFunction -> Ordering -> RegularFunction
when you can do RegularFunction -> RegularFunction
?
But why would you want this? I feel like this case is way better? You have all the logic of the regularfunctions in this one file? Why would you want to go: RegularFunction -> Ordering -> RegularFunction when you can do RegularFunction -> RegularFunction?
~~Not sure I understand you correctly.
What I suggest is to just delegate to the orderTypes
function. AFAIK, orderTypes
has no external references back to regular functions.~~
I just looked again at #180, and now I understand your comment, because you did add a back-reference to regular functions from type ordering there.
Closes comunica/sparqlee#178
This PR aims to resolve https://github.com/comunica/sparqlee/issues/178 (working together but not dependent on each other is: https://github.com/comunica/sparqlee/pull/180)