[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[rdf4j-dev] Visitor pattern or ...
|
- From: jerven Bolleman <jerven.bolleman@sib.swiss>
- Date: Mon, 28 Nov 2022 22:44:37 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sib.swiss; dmarc=pass action=none header.from=sib.swiss; dkim=pass header.d=sib.swiss; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+Hjd7BFsv2NoYibhNj+wi+E0pHQx0Jn9UMvysizdD4Y=; b=nng/ssAQMLPvhhXv4lF/j40AKO9QPAa7HVWseyLfhkUXGyNh0nmt6FVtT3Us9+goKafqgxNWwMYhd5LT7ldseKzWGGh+50k+g6YrG4BZr2zsh8/wr01v+zIJaxoOHptGC1gqyObYZS4Jhe184KnuHk2sAzZwIx51nywDKwyyrleqtRlkCyv6xVw9PBWck67ayj5HkG+yvA/UeabzwUkSt5UkgtJSt01H2FSUXsCzCoL26GRN+IME9rj2h6HbKv5jVswPeBi9K+JECa/Yq1rzgOxXPjJNPUUhtLF64VRhhHz2aR5QkTmz+/GwQRMdyV9Dk4WMk1ii8jfpxGQDrbsg2A==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fndXNE4uWTKgayTHvF+3NEbn/E/+txiSQWo6wSsUoEqzd+dOZTrwsEJeoN1KNb9uPDaeG2xRlcoO6ewKMenBQkMAE8gU/ZpVyEF4gr0oryWcGZn/ZvwxSkB65izuK9IxyCzHD8KLz+ba1OGpZalB7WkJkAYlLjXvHvf/rrKa/a9S1Fpmdg3rxa/dSJSGiQxx/6dZmRZmQnR7jvafcbc6mtsSocWHbwfnZA4HMdfdzpo6pAeSUq3b6RWETEbnvYowyV0e6Vn4eFjrADCP4zsnx+0RgVfr/CxAfWL3mxJIG6jMY1EoS+oxYzhhrys6jgkrVosDRTTrb9JBXLdRpdKR7Q==
- Delivered-to: rdf4j-dev@xxxxxxxxxxx
- List-archive: <https://www.eclipse.org/mailman/private/rdf4j-dev/>
- List-help: <mailto:rdf4j-dev-request@eclipse.org?subject=help>
- List-subscribe: <https://www.eclipse.org/mailman/listinfo/rdf4j-dev>, <mailto:rdf4j-dev-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://www.eclipse.org/mailman/options/rdf4j-dev>, <mailto:rdf4j-dev-request@eclipse.org?subject=unsubscribe>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1
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
>
https://github.com/eclipse/rdf4j/blob/7fc970aa1fe27308bb44ec20d106e56e6353fdc9/core/queryalgebra/evaluation/src/main/java/org/eclipse/rdf4j/query/algebra/evaluation/impl/StrictEvaluationStrategy.java#L919)?
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.
https://docs.oracle.com/en/java/javase/19/language/sealed-classes-and-interfaces.html
https://docs.oracle.com/en/java/javase/19/language/pattern-matching-switch-expressions-and-statements.html#GUID-E69EEA63-E204-41B4-AA7F-D58B26A3B232
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
https://github.com/eclipse/rdf4j/blob/c607df2ace72eba12d6a3f9586b7fec4b8886129/core/queryalgebra/evaluation/src/main/java/org/eclipse/rdf4j/query/algebra/evaluation/impl/ConstantOptimizer.java#L248). Do we want that? So if I pass in an unregistered function, shouldn't the exception bubble up here?
you can test it with against 4.2.1 workbench:
PREFIX fn: <http://example.com/>
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
https://github.com/eclipse/rdf4j/blob/7fc970aa1fe27308bb44ec20d106e56e6353fdc9/core/queryalgebra/evaluation/src/main/java/org/eclipse/rdf4j/query/algebra/evaluation/impl/StrictEvaluationStrategy.java#L919)? Looks like we would need one for evaluation/prepare if I'm reading this right. So something like:
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
rdf4j-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/rdf4j-dev
--
*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
Jerven.Bolleman@sib.swiss - www.sib.swiss