[
https://issues.apache.org/jira/browse/TINKERPOP3-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720710#comment-14720710
]
Matt Frantz commented on TINKERPOP3-818:
----------------------------------------
It seems that we are circling a type registry of some sort.
* Gremlin core has requirements for specific types: Element, Vertex, Edge, Map,
String, etc.
* Vendors may have specific property types: Int64, Timestamp, Counter, etc.
* Applications have schema types: Person, InetAddress, etc.
While the Java API provides a measure of type declaration and safety, we seek a
solution that transcends the language binding. Use cases include the following:
* Runtime type checking, {{P.instanceOf}} TINKERPOP3-818
* Instantiation/coercion, {{curry}} TINKERPOP3-788
* User-defined containers, {{withMap}}/{{withList}} TINKERPOP3-787
* Comparison TINKERPOP3-750
The solution probably involves some kind of type specifier, which is a string
that points to a registry entry. Vendors should be able to register types
available on a graph. Applications should be able to register types available
on a traversal or strategy. Server-side registration involves units of code,
which can be Java classes or dynamically linked libraries (for non-JVM
backends). Client-side registration involves units of code that are
serializable lambdas or traversals. The goal is interoperability with specific
delivery vehicles, e.g. JVM byte code, Groovy source code, etc.
Should we create some sort of "epic" or moral equivalent container issue to
track this?
> Consider a P.instanceOf()
> -------------------------
>
> Key: TINKERPOP3-818
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-818
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.0-incubating
> Reporter: stephen mallette
> Assignee: Marko A. Rodriguez
> Priority: Minor
>
> A predicate that checks the type of the value passing through the traversal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
