Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/49#discussion_r69671763
--- Diff:
lucene/queries/src/java/org/apache/lucene/queries/function/valuesource/CompareNumericFunction.java
---
@@ -0,0 +1,131 @@
+package org.apache.lucene.queries.function.valuesource;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import java.io.IOException;
+import java.util.Map;
+
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.queries.function.ValueSource;
+import org.apache.lucene.queries.function.FunctionValues;
+import org.apache.lucene.search.IndexSearcher;
+
+
+/**
+ * Base class for comparison operators used within if statements
+ * To Solr's if function query a 0 is considered "false", all other values
are "true"
+ */
+public abstract class CompareNumericFunction extends ValueSource {
+
+ public final ValueSource lhs;
+ public final ValueSource rhs;
+
+ public CompareNumericFunction(ValueSource lhs, ValueSource rhs) {
+ this.lhs = lhs;
+ this.rhs = rhs;
+ }
+
+ // Perform the comparison, returning true or false
+ public abstract boolean compareNumeric(double lhs, double rhs);
--- End diff --
Instead of making this an abstract class, what do you think of making it
concrete and take the label and a simple interface named something like
LongBinaryPredicate (a specialization of JDK java.util.BiPredicate), then
creating some singleton instances? I would reduce all these subclasses. A
smaller change that reduces the top-level classes you create here is to make
the subclasses in fact inner classes or even anonymous inner classes to
initialize some singleton instances of them. I think I like that a little
better in that there is no need to create a new interface (even if it is an
inner one). I welcome your input.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
