[
https://issues.apache.org/jira/browse/TINKERPOP-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18022534#comment-18022534
]
ASF GitHub Bot commented on TINKERPOP-2234:
-------------------------------------------
spmallette commented on code in PR #3211:
URL: https://github.com/apache/tinkerpop/pull/3211#discussion_r2376885126
##########
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/Type.java:
##########
@@ -0,0 +1,123 @@
+/*
+ * 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.
+ */
+package org.apache.tinkerpop.gremlin.process.traversal;
+
+import java.util.Map;
+import java.util.Optional;
+import java.util.concurrent.ConcurrentHashMap;
+
+/**
+ * {@code Type} is a {@code BiPredicate} that determines whether the first
argument is a type of the second argument.
+ *
+ */
+public enum Type implements PBiPredicate<Object, Object> {
Review Comment:
I think [my
comment](https://github.com/apache/tinkerpop/pull/3207/files#r2352474590) still
stands from the proposal. I still think `Type` should be better constrained by
that `<Object, Object>` and that `<Object, Class<?>>` is more agreeable. Doing
so would also get rid of the catch-all `else { return false }` and that check
for `GType.NULL`:
```java
typeOf {
@Override
public boolean test(final Object first, final Class<?> second) {
if (first == null) return false;
return secondClass.isAssignableFrom(first.getClass());
}
};
```
This way, it can never be called other than how it is intended. In `P` you
already have the types constrained to multiple `typeOf` overloads. Why expand
them back to the `Type` enum when you can just coerce them each to `Class<?>`
by moving that logic I removed above back to those specific `P` overloads?
Also, you'd catch `GlobalTypeCache` failures at traversal construction time
with that logic in `P` rather than at runtime which seems more advantageous to
me.
Do we lose something by getting more strict with the types for the `Type`
enum?
As a separate point, are we making a mistake using `Type` for the name of
this enum? We have `Type` and `GType` and at some point in the future we will
have a schema. "Type" is such a great word to save for when we really need it.
We currently have `Contains`, `Compare` , and the unfortunately named `Text`.
The first two are verbs which actively define what `P` is doing - containing or
comparing. Maybe there's a verb form that would be better than `Type`? Maybe
we call the enum `InstanceOf` rather than `Type`- that's pretty normal and
understood?
> Introduce Type Predicate
> ------------------------
>
> Key: TINKERPOP-2234
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2234
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.4.2
> Reporter: Stephen Mallette
> Priority: Major
>
> Provide for a {{typeOf()}} predicate that allows for testing the type of an
> object which would enable neat things like:
> {code}
> g.V().outE().has('weight',gt(0.1)).inV().path().unfold().is(typeOf(VERTEX))
> {code}
> See the linked DISCUSS thread for more information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
