You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Marko Rodriguez <ok...@gmail.com> on 2019/03/18 14:29:43 UTC
Thoughts on is(), where(), select(), and path() for TP4.
Hi,
In TP4, Bytecode instruction arguments can be Bytecode. Well of course, this is like in TP3 --- nested traversals (union(), repeat(), etc.). However! — Bytecode can also be used for singleton arguments. For instance:
has(“name”,select(“a”).value(“name”))
is(gt(select(“a”).out().count()))
Thus, what were “constant” arguments in TP3 can now be “dynamic” (traversal-determined) arguments.
Because arguments can be traversals, various steps are starting to blend into each other:
is(gt(select(“a”))) <=> where(gt(“a”))
Now, we can keep where() in Gremlin, but at the bytecode level, it can just translate to an is() instruction. However, perhaps we can remove one from the Gremlin language…?
Another thing that I want to clean up in Gremlin4 is select(). We have overloaded this step to the extreme where it can:
1. select a value from the incoming Map.
2. select an object from the Path history.
3. select a sideEffect from global side-effects.
I think we should split it up:
1. select() for getting value from incoming Map.
2. path() for getting an object from a Path history.
3. … I don’t know if we will have global side-effects in TP4.
Thus,
g.V().as(“a”).out().as(“b”).select(“a”,”b”).by(“name”)
would become…
g.V().as(“a”).out().as(“b’).path(“a”,”b”).by(“name”)
Next, if we assume that Vertex and Edge are “MapLike”, then what is the difference between values() and select()?
g.V().values(“name”)
g.V().select(“name”)
Any thoughts on the future of is(), where(), select(), and path() would be appreciated.
Thanks,
Marko.
http://markorodriguez.com
Re: Thoughts on is(), where(), select(), and path() for TP4.
Posted by Stephen Mallette <sp...@gmail.com>.
>
> > 1. select() for getting value from incoming Map.
> > 2. path() for getting an object from a Path history.
>
> Great, I like that.
> g.V().values(“name”)
> > g.V().select(“name”)
>
> Cool, let's get rid of values().
the above points make sense to me. i usually start answers in to user
questions like, "Well, here's one way to do it...." which speaks to the
point of one of the complaints we see fairly consistently is that there are
too many ways to do the same thing in Gremlin. The more aspects of the
language that can have distinct purposes the better.
On Tue, Mar 19, 2019 at 12:46 PM Daniel Kuppitz <me...@gremlin.guru> wrote:
> >
> > 1. select() for getting value from incoming Map.
> > 2. path() for getting an object from a Path history.
>
>
> Great, I like that.
>
> 3. … I don’t know if we will have global side-effects in TP4.
>
>
> Hm, I don't know why you have any doubts about that. I think global
> side-effects will be necessary and the functionality around them should be
> extended (e.g. we need the clear() step to reset aggregations).
>
> g.V().values(“name”)
> > g.V().select(“name”)
>
>
> Cool, let's get rid of values().
>
> Cheers,
> Daniel
>
>
>
> On Mon, Mar 18, 2019 at 7:29 AM Marko Rodriguez <ok...@gmail.com>
> wrote:
>
> > Hi,
> >
> > In TP4, Bytecode instruction arguments can be Bytecode. Well of course,
> > this is like in TP3 --- nested traversals (union(), repeat(), etc.).
> > However! — Bytecode can also be used for singleton arguments. For
> instance:
> >
> > has(“name”,select(“a”).value(“name”))
> > is(gt(select(“a”).out().count()))
> >
> > Thus, what were “constant” arguments in TP3 can now be “dynamic”
> > (traversal-determined) arguments.
> >
> > Because arguments can be traversals, various steps are starting to blend
> > into each other:
> >
> > is(gt(select(“a”))) <=> where(gt(“a”))
> >
> > Now, we can keep where() in Gremlin, but at the bytecode level, it can
> > just translate to an is() instruction. However, perhaps we can remove one
> > from the Gremlin language…?
> >
> > Another thing that I want to clean up in Gremlin4 is select(). We have
> > overloaded this step to the extreme where it can:
> >
> > 1. select a value from the incoming Map.
> > 2. select an object from the Path history.
> > 3. select a sideEffect from global side-effects.
> >
> > I think we should split it up:
> >
> > 1. select() for getting value from incoming Map.
> > 2. path() for getting an object from a Path history.
> > 3. … I don’t know if we will have global side-effects in TP4.
> >
> > Thus,
> >
> > g.V().as(“a”).out().as(“b”).select(“a”,”b”).by(“name”)
> >
> > would become…
> >
> > g.V().as(“a”).out().as(“b’).path(“a”,”b”).by(“name”)
> >
> > Next, if we assume that Vertex and Edge are “MapLike”, then what is the
> > difference between values() and select()?
> >
> > g.V().values(“name”)
> > g.V().select(“name”)
> >
> > Any thoughts on the future of is(), where(), select(), and path() would
> be
> > appreciated.
> >
> > Thanks,
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
> >
> >
>
Re: Thoughts on is(), where(), select(), and path() for TP4.
Posted by Daniel Kuppitz <me...@gremlin.guru>.
>
> 1. select() for getting value from incoming Map.
> 2. path() for getting an object from a Path history.
Great, I like that.
3. … I don’t know if we will have global side-effects in TP4.
Hm, I don't know why you have any doubts about that. I think global
side-effects will be necessary and the functionality around them should be
extended (e.g. we need the clear() step to reset aggregations).
g.V().values(“name”)
> g.V().select(“name”)
Cool, let's get rid of values().
Cheers,
Daniel
On Mon, Mar 18, 2019 at 7:29 AM Marko Rodriguez <ok...@gmail.com>
wrote:
> Hi,
>
> In TP4, Bytecode instruction arguments can be Bytecode. Well of course,
> this is like in TP3 --- nested traversals (union(), repeat(), etc.).
> However! — Bytecode can also be used for singleton arguments. For instance:
>
> has(“name”,select(“a”).value(“name”))
> is(gt(select(“a”).out().count()))
>
> Thus, what were “constant” arguments in TP3 can now be “dynamic”
> (traversal-determined) arguments.
>
> Because arguments can be traversals, various steps are starting to blend
> into each other:
>
> is(gt(select(“a”))) <=> where(gt(“a”))
>
> Now, we can keep where() in Gremlin, but at the bytecode level, it can
> just translate to an is() instruction. However, perhaps we can remove one
> from the Gremlin language…?
>
> Another thing that I want to clean up in Gremlin4 is select(). We have
> overloaded this step to the extreme where it can:
>
> 1. select a value from the incoming Map.
> 2. select an object from the Path history.
> 3. select a sideEffect from global side-effects.
>
> I think we should split it up:
>
> 1. select() for getting value from incoming Map.
> 2. path() for getting an object from a Path history.
> 3. … I don’t know if we will have global side-effects in TP4.
>
> Thus,
>
> g.V().as(“a”).out().as(“b”).select(“a”,”b”).by(“name”)
>
> would become…
>
> g.V().as(“a”).out().as(“b’).path(“a”,”b”).by(“name”)
>
> Next, if we assume that Vertex and Edge are “MapLike”, then what is the
> difference between values() and select()?
>
> g.V().values(“name”)
> g.V().select(“name”)
>
> Any thoughts on the future of is(), where(), select(), and path() would be
> appreciated.
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
>
>
>