On Monday, November 28, 2022 at 04:44:49 PM EST, jerven Bolleman <jerven.bolleman@sib.swiss> wrote:
Hi Matt, Jeen,
> 2. should we normalize these calls to the ValueExpr derived classes so
> we don't have these large if instanceOf/else checks (eg
>
Looks like we would need one for evaluation/prepare if I'm reading
this right. So something like:
So what you are proposing is a classic visitor pattern and I have
thought about this a lot. But in the end I thought not to go that way
right now. Because I think when pattern matching comes we will want to
use that instead. Probably with a sealed interface for all algebra members.
Also in 5.x I want to get rid of the evaluate methods and have only prepare.
So it felt like a lot of code churn for no long term benefit. Or not
enough benefit for me to be the one to do it ;) A second issue is that
it set's how something should be evaluated in the algebra. While I think
the evaluation choice is independent of the algebra. e.g. hash join/or
merge sorted join is an evaluation choice.
Regards,
Jerven
On 23/11/2022 15:29, Matthew Nguyen via rdf4j-dev wrote:
> Hey folks, debugging some things and noticed the following that I wanted
> to get a take on:
>
> 1. Some of these optimizers are eating the exceptions (eg
>
> you can test it with against 4.2.1 workbench:
>
> SELECT ?whatever
> WHERE {
> BIND (fn:whatever("foo") AS ?whatever)
> }
>
> and it just silently fails.
>
> 2. should we normalize these calls to the ValueExpr derived classes so
> we don't have these large if instanceOf/else checks (eg
>
> expr.acceptEval(this, bindings) and expr.acceptPrepare(this, context)
>
>
> and the derived classes would just call the appropriate evaluate/prepare
> through the accepted 'this' object. Would save a few cycles on the
> if/else checks I would think. Also a little cleaner/less casting and
> any new _expression_ class would need to implement it if these were made
> abstract in the base and less likely to break b/c we forgot to add the
> corresponding if/else check.
>
> matt
>
> _______________________________________________
> rdf4j-dev mailing list
--
*Jerven Tjalling Bolleman*
Principal Software Developer
*SIB | Swiss Institute of Bioinformatics*
1, rue Michel Servet - CH 1211 Geneva 4 - Switzerland
t +41 22 379 58 85
_______________________________________________
rdf4j-dev mailing list
