> Another question might be, does adding this notion of Type create other
interesting opportunities that should be considered before we keep it
confined to a narrow use case (i.e. just type checking in Gremlin)?
One of opportunities could be type conversion. In addition to
`isInstance(Object)`, `Type` interface could have `convert(Object)` method that
will convert input to this type (e.g. String → Numeric) or throw
exception/return nothing if conversion is not possible. New step for type
conversion could be introduced:
`g.V().values('age').convertTo(ProviderTypeImpl.string)`
`g.inject(1).math('_ + 1').convertTo(ProviderTypeImpl.integer)`
On 2019/05/29 12:54:03, Stephen Mallette <[email protected]> wrote:
> >
> > Also, it may seem tempting to support as many types as possible, but I
> > don't think we need that. Whenever I was in need of a type-check, I usually
> > had to figure out if the element is a vertex or an edge. Hence, a small set
> > of predefined types is probably good enough: Vertex, Edge, Property
>
>
> Well, those are the top uses from what I've come across in my Gremlin
> career. The full GraphSON/GraphBinary list was probably a bit much to
> suggest because there's a ton of stuff there that likely isn't relevant to
> type testing in Gremlin - for example, P itself or an enum like Scope. I
> think I'd be into doing the graph elements (vertex, edge, property,
> vertexproperty, path, tree) plus the primitives and base collections (Set,
> List, Map). That's not a whole lot of stuff really. I think I'm also still
> interested in thinking through the extension model for providers as I don't
> want to get us painted into a corner with whatever we implement now.
>
> Actually, as I think on it now, I don't think the extension model is all
> that complicated. I assume we would have a form of Type interface that
> would be passed as P.type(Type) and Type would have it's own method for
> that type check. Providers would just create their own implementations of
> Type and expose them to users as needed.
>
> Another question might be, does adding this notion of Type create other
> interesting opportunities that should be considered before we keep it
> confined to a narrow use case (i.e. just type checking in Gremlin)? Is
> there a bigger picture to consider? I don't mean that we need to expand
> scope as part of this body of work, just that if there are other areas
> where this is useful it would be nice to at least have an idea as to what
> that might be so that it can be accounted for as part of what we're
> currently discussing.
>
> On Tue, May 28, 2019 at 10:51 AM Daniel Kuppitz <[email protected]> wrote:
>
> > +1 to have it as a predicate.
> >
> > Also, it may seem tempting to support as many types as possible, but I
> > don't think we need that. Whenever I was in need of a type-check, I usually
> > had to figure out if the element is a vertex or an edge. Hence, a small set
> > of predefined types is probably good enough: Vertex, Edge, Property
> >
> > Chers,
> > Daniel
> >
> >
> > On Tue, May 28, 2019 at 3:39 AM Stephen Mallette <[email protected]>
> > wrote:
> >
> > > I've often thought of this feature more as a filter step than a
> > predicate,
> > > but I suppose is() would work - I'd be curious to know what Daniel
> > > thinks...
> > >
> > > > TinkerPop 3 type system depends on the implementation, but there are
> > some
> > > common types like Vertex, Edge, Map, List, String...
> > >
> > > I'm not sure how we want to go about providing the available types we
> > could
> > > test against. I would imagine that they should be bound to the
> > > GraphSON/GraphBinary types somehow and should be extensible to provider
> > > types. If this sort of feature were to release without the latter, it
> > won't
> > > long before the questions start coming in about "how do I check for a
> > Point
> > > type?" or whatever.
> > >
> > > > outE().inV().path().unfold().is( type(Type.vertex) )
> > >
> > > Of all your examples, this is the one that I feel users probably come
> > > entangled with the most.
> > >
> > > > This requirement is actual for Cypher for Gremlin.
> > >
> > > I think this feature request has wider applicability than just
> > > translation....we have junky workarounds for type testing. I think that
> > I'd
> > > like to see this change in 3.5.0. Let's see where the discussion goes as
> > to
> > > exactly how it would work.
> > >
> > > On Mon, May 27, 2019 at 9:49 AM Dmitry Novikov <
> > [email protected]>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I am aware that all of this will be improved in TinkerPop 4.
> > > >
> > > > Suggestion to introduce type predicates in TinkerPop 3:
> > > >
> > > > `...is(P.vertexType())...` or `...is(P.type(Type.vertex))...`
> > > >
> > > > with imports:
> > > >
> > > > `...is(vertexType())...` or `...is(P.type(vertex))...`
> > > >
> > > > TinkerPop 3 type system depends on the implementation, but there are
> > some
> > > > common types like Vertex, Edge, Map, List, String...
> > > >
> > > > Depending on the type, different steps are required to perform similar
> > > > operations. For example, access by index:
> > > >
> > > > * `values(i)` to get property from vertex or edge
> > > > * `select(i)` to get value from map
> > > >
> > > > In complex traversals, it might be complicated to track type. This
> > might
> > > > be improved by introducing type predicates:
> > > >
> > > > `...select('unknown').choose(mapType(), select('p'), values('p'))`
> > > >
> > > > Another use case - filter path elements. For example, getting all
> > > vertices
> > > > from path with mixed order of elements
> > > > `g.V().limit(1).out().out().inE().outV().path().as('myPath)` is not
> > > > trivial task. This could be achieved by:
> > > >
> > > > `...select('myPath').unfold().is(vertexType())`
> > > >
> > > > Some steps depend on type:
> > > >
> > > > `g.V().values('prop1').max()` will fail with `java.lang.Integer cannot
> > be
> > > > cast to java.lang.String` if `prop1` has different types. This could be
> > > > addressed:
> > > >
> > > > `g.V().values('prop1').is(numericType()).max()`
> > > >
> > > > This requirement is actual for Cypher for Gremlin. I am very interested
> > > to
> > > > know if this requirement is language translation specific, or have
> > other
> > > > use cases.
> > > >
> > > > Please share your opinion on this.
> > > >
> > > > Regards,
> > > > Dmitry
> > > >
> > > >
> > >
> >
>
