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 2015/08/18 21:06:05 UTC
Re: [TinkerPop] describeSteps()
Hi Stephen,
I wouldn't add this just yet. I would not promote "normal users" working with Steps directly as:
1. There typing will likely change soon given the work in "Gremlin Traversal Machine and Language."
2. We don't have a DSL path yet.
3. The interface API will most likely change as well.
Finally, I don't know what use this would have as a "runtime call." If someone is developing a traversal language using the "instruction set" of Gremlin, they will most likely be in JavaDoc-land, not in describeSteps()-land. ??
Perhaps, for now, you can pull this into a feature branch.
Thanks,
Marko.
http://markorodriguez.com
On Aug 18, 2015, at 10:32 AM, Stephen Mallette <sp...@gmail.com> wrote:
> I just wanted to quickly mention a minor new feature that will be available in 3.1.0. It is an addition to the utilities plugin and is basically a function called describeSteps(). When it is called from the Gremlin Console it will scan the classpath for all non-abstract Step implementations and print them in a table to display which important base classes and marker interfaces they extend/implement. This kind of information will be useful to those developing core API/TraversalStrategy implementations. You can see its usage in this gist:
>
> https://gist.github.com/spmallette/e12aebc8a747623059c4
>
> --
> You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/CAA-H43-pxcn9SFhjLiRu7y7yWcjF7hZkkJeb%3DAfVJJBjZ5CHEw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
Re: [TinkerPop] describeSteps()
Posted by Marko Rodriguez <ok...@gmail.com>.
Hey,
> You sound like you're setting up to break the world with changes coming
> down the pike. :) I mostly wanted a way to see all the steps at once with
> their key features present. That's all it's meant to do. I don't
> understand how it locks anyone into anything in particular, but perhaps you
> have some vision into something i'm not getting yet.
Just wait until someone string parses the describeStep() toString() and uses it to do something wildly lame and then we get the email:
"EVERYTHING BROKEN! I HAZZZ big DEMOZ TOMORROW?!?!?!! WHY HasStep NO LONGER have X in F-column?!? Why F-column also no LONGERZZZZZZzzz the second column?! My boss is upset -- I have children to feed. Does TinkerPop not careZZZZ ABOUTZ my CHILDREN!!?!"
If the feature isn't compelling, don't add it. JavaDoc is sufficient for what you are trying to accomplish with describeStep()… However, your describeGraph() work, genius. To bring it to your area of the codebase, why don't you create describeGryo() or describeREST()? Not so fun anymore, eh? Why, why, why would such things need to be a runtime toString() in a REPL? ………
> anyway, it's 40 lines of code - i'm not going to create a branch over
> that. You seem to feel pretty strongly about it so i'm content to remove
> it.
Yes. Very strongly. I think about steps and traversals day in and day out. describeSteps() is wrench in the path for where I see Gremlin's instruction set evolving.
Thanks Stephen,
Marko.
http://markorodriguez.com
>
>
> On Tue, Aug 18, 2015 at 6:48 PM, Marko Rodriguez <ok...@gmail.com>
> wrote:
>
>> Hey,
>>
>> I don't think its a useful feature and not something worth
>> maintaining/exposing.
>>
>> HasStep --- okay, so its a filter. ? … parameters, arguments… ? What does
>> it do? What types does it take? What types does it emit? by() modulation?
>>
>>> I don't see why that's a problem really - the table is dynamically
>> driven.
>>> If we refactor, it's really not that big a deal to change.
>>
>>
>> Seems you would only use it in the context of a REPL as its a toString()
>> like describeGraph(). For describeGraph(), makes a lot of sense as Features
>> are very "for the user." For steps, not so much. Its so low-level that to
>> give us (TinkerPop) more degrees of freedom at the instruction level, why
>> ground it for the general user? Especially so early in the game at 3.1.0.
>> If the user depends on that table to be as it is at 3.1.0+ … damn, locked
>> in. I think its way to early to start making such promises.
>>
>>>> 2. We don't have a DSL path yet.
>>>>
>>>
>>> we haven't discussed all the goals of 3.1.0 but the approach to DSLs
>> should
>>> be part of that release - so in that sense it doesn't seem premature to
>> me
>>> to have this feature in that branch.
>>
>> Why should 3.1.0 have DSL? It would be good, but not forced. Moreover,
>> describeSteps() doesn't really help for DSL constructions. You would go to
>> the JavaDoc.
>>
>> - What are all the steps?
>>
>> http://tinkerpop.incubator.apache.org/javadocs/3.0.0-incubating/full/org/apache/tinkerpop/gremlin/process/traversal/step/filter/package-summary.html
>> - What is this particular step?
>>
>> http://tinkerpop.incubator.apache.org/javadocs/3.0.0-incubating/full/org/apache/tinkerpop/gremlin/process/traversal/step/filter/HasStep.html
>> - What is the paragraph description of what it does?
>> … we should put our effort in better JavaDoc :D
>> - What interfaces does it implement?
>>
>> http://tinkerpop.incubator.apache.org/javadocs/3.0.0-incubating/full/org/apache/tinkerpop/gremlin/process/traversal/step/HasContainerHolder.html
>> - What are those interfaces paragraph descriptions?
>> … again, better JavaDoc is needed.
>>
>> A runtime toString() table of 1/4 of that information doesn't seem useful
>> especially against the backdrop of users depending on it (as we all know,
>> users do crazy things once you expose stuff).
>>
>>> Having it as a utility allows us to generate it into the docs in
>> real-time
>>> (not as some static data we have to manage manually). I also believe
>> that
>>> a table is helpful from both a development and QA perspective. javadoc
>>> doesn't make it as easy to see in once place what all the relationships
>> are
>>> among the steps. Finally, there will be steps outside of those
>> maintained
>>> by TinkerPop and since this utility operates by doing a scan of the
>>> classpath for Step implementations, it will capture those on the
>> classpath
>>> of the console as well and work them into the table.
>>
>> We have to be very careful about letting people consider "steps outside"
>> TinkerPop. This is something TraversalStrategy work has taught us. Unless
>> you are a graph systems vendor (and I have ideas for constraining them),
>> you should not be creating steps outside of TinkerPop. This is the idea of
>> a static "Gremlin instruction set." Another reason why hiding steps and all
>> this low-level stuff is important at this point in time.
>>
>> I would remove it. However, at least, put it into a feature branch and not
>> into master/.
>>
>> Thanks,
>> Marko.
>>
>> http://markorodriguez.com
>>
>>
>>>
>>>
>>>
>>> On Tue, Aug 18, 2015 at 3:06 PM, Marko Rodriguez <ok...@gmail.com>
>>> wrote:
>>>
>>>> Hi Stephen,
>>>>
>>>> I wouldn't add this just yet. I would not promote "normal users" working
>>>> with Steps directly as:
>>>>
>>>> 1. There typing will likely change soon given the work in "Gremlin
>>>> Traversal Machine and Language."
>>>> 2. We don't have a DSL path yet.
>>>> 3. The interface API will most likely change as well.
>>>>
>>>> Finally, I don't know what use this would have as a "runtime call." If
>>>> someone is developing a traversal language using the "instruction set"
>> of
>>>> Gremlin, they will most likely be in JavaDoc-land, not in
>>>> describeSteps()-land. ??
>>>>
>>>> Perhaps, for now, you can pull this into a feature branch.
>>>>
>>>> Thanks,
>>>> Marko.
>>>>
>>>> http://markorodriguez.com
>>>>
>>>> On Aug 18, 2015, at 10:32 AM, Stephen Mallette <sp...@gmail.com>
>>>> wrote:
>>>>
>>>> I just wanted to quickly mention a minor new feature that will be
>>>> available in 3.1.0. It is an addition to the utilities plugin and is
>>>> basically a function called describeSteps(). When it is called from the
>>>> Gremlin Console it will scan the classpath for all non-abstract Step
>>>> implementations and print them in a table to display which important
>> base
>>>> classes and marker interfaces they extend/implement. This kind of
>>>> information will be useful to those developing core
>> API/TraversalStrategy
>>>> implementations. You can see its usage in this gist:
>>>>
>>>> https://gist.github.com/spmallette/e12aebc8a747623059c4
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>> Groups
>>>> "Gremlin-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>> an
>>>> email to gremlin-users+unsubscribe@googlegroups.com.
>>>> To view this discussion on the web visit
>>>>
>> https://groups.google.com/d/msgid/gremlin-users/CAA-H43-pxcn9SFhjLiRu7y7yWcjF7hZkkJeb%3DAfVJJBjZ5CHEw%40mail.gmail.com
>>>> <
>> https://groups.google.com/d/msgid/gremlin-users/CAA-H43-pxcn9SFhjLiRu7y7yWcjF7hZkkJeb%3DAfVJJBjZ5CHEw%40mail.gmail.com?utm_medium=email&utm_source=footer
>>>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>> Groups
>>>> "Gremlin-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>> an
>>>> email to gremlin-users+unsubscribe@googlegroups.com.
>>>> To view this discussion on the web visit
>>>>
>> https://groups.google.com/d/msgid/gremlin-users/BA0F5FFE-239B-43DB-B3FE-A4C811D7572C%40gmail.com
>>>> <
>> https://groups.google.com/d/msgid/gremlin-users/BA0F5FFE-239B-43DB-B3FE-A4C811D7572C%40gmail.com?utm_medium=email&utm_source=footer
>>>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>
>>
Re: [TinkerPop] describeSteps()
Posted by Stephen Mallette <sp...@gmail.com>.
You sound like you're setting up to break the world with changes coming
down the pike. :) I mostly wanted a way to see all the steps at once with
their key features present. That's all it's meant to do. I don't
understand how it locks anyone into anything in particular, but perhaps you
have some vision into something i'm not getting yet.
DSLs should be part of 3.1.0 - the mailing list has many ongoing questions
about what what the patterns are for doing it and our answers are pretty
dumpy. They're writing strategies to try to work around the lack of
wrappers without clear guidance as to how DSLs fit into that. I think that
issue and bulk loading are the two biggest things to tackle right now for
3.1.0.
anyway, it's 40 lines of code - i'm not going to create a branch over
that. You seem to feel pretty strongly about it so i'm content to remove
it.
On Tue, Aug 18, 2015 at 6:48 PM, Marko Rodriguez <ok...@gmail.com>
wrote:
> Hey,
>
> I don't think its a useful feature and not something worth
> maintaining/exposing.
>
> HasStep --- okay, so its a filter. ? … parameters, arguments… ? What does
> it do? What types does it take? What types does it emit? by() modulation?
>
> > I don't see why that's a problem really - the table is dynamically
> driven.
> > If we refactor, it's really not that big a deal to change.
>
>
> Seems you would only use it in the context of a REPL as its a toString()
> like describeGraph(). For describeGraph(), makes a lot of sense as Features
> are very "for the user." For steps, not so much. Its so low-level that to
> give us (TinkerPop) more degrees of freedom at the instruction level, why
> ground it for the general user? Especially so early in the game at 3.1.0.
> If the user depends on that table to be as it is at 3.1.0+ … damn, locked
> in. I think its way to early to start making such promises.
>
> >> 2. We don't have a DSL path yet.
> >>
> >
> > we haven't discussed all the goals of 3.1.0 but the approach to DSLs
> should
> > be part of that release - so in that sense it doesn't seem premature to
> me
> > to have this feature in that branch.
>
> Why should 3.1.0 have DSL? It would be good, but not forced. Moreover,
> describeSteps() doesn't really help for DSL constructions. You would go to
> the JavaDoc.
>
> - What are all the steps?
>
> http://tinkerpop.incubator.apache.org/javadocs/3.0.0-incubating/full/org/apache/tinkerpop/gremlin/process/traversal/step/filter/package-summary.html
> - What is this particular step?
>
> http://tinkerpop.incubator.apache.org/javadocs/3.0.0-incubating/full/org/apache/tinkerpop/gremlin/process/traversal/step/filter/HasStep.html
> - What is the paragraph description of what it does?
> … we should put our effort in better JavaDoc :D
> - What interfaces does it implement?
>
> http://tinkerpop.incubator.apache.org/javadocs/3.0.0-incubating/full/org/apache/tinkerpop/gremlin/process/traversal/step/HasContainerHolder.html
> - What are those interfaces paragraph descriptions?
> … again, better JavaDoc is needed.
>
> A runtime toString() table of 1/4 of that information doesn't seem useful
> especially against the backdrop of users depending on it (as we all know,
> users do crazy things once you expose stuff).
>
> > Having it as a utility allows us to generate it into the docs in
> real-time
> > (not as some static data we have to manage manually). I also believe
> that
> > a table is helpful from both a development and QA perspective. javadoc
> > doesn't make it as easy to see in once place what all the relationships
> are
> > among the steps. Finally, there will be steps outside of those
> maintained
> > by TinkerPop and since this utility operates by doing a scan of the
> > classpath for Step implementations, it will capture those on the
> classpath
> > of the console as well and work them into the table.
>
> We have to be very careful about letting people consider "steps outside"
> TinkerPop. This is something TraversalStrategy work has taught us. Unless
> you are a graph systems vendor (and I have ideas for constraining them),
> you should not be creating steps outside of TinkerPop. This is the idea of
> a static "Gremlin instruction set." Another reason why hiding steps and all
> this low-level stuff is important at this point in time.
>
> I would remove it. However, at least, put it into a feature branch and not
> into master/.
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
>
> >
> >
> >
> > On Tue, Aug 18, 2015 at 3:06 PM, Marko Rodriguez <ok...@gmail.com>
> > wrote:
> >
> >> Hi Stephen,
> >>
> >> I wouldn't add this just yet. I would not promote "normal users" working
> >> with Steps directly as:
> >>
> >> 1. There typing will likely change soon given the work in "Gremlin
> >> Traversal Machine and Language."
> >> 2. We don't have a DSL path yet.
> >> 3. The interface API will most likely change as well.
> >>
> >> Finally, I don't know what use this would have as a "runtime call." If
> >> someone is developing a traversal language using the "instruction set"
> of
> >> Gremlin, they will most likely be in JavaDoc-land, not in
> >> describeSteps()-land. ??
> >>
> >> Perhaps, for now, you can pull this into a feature branch.
> >>
> >> Thanks,
> >> Marko.
> >>
> >> http://markorodriguez.com
> >>
> >> On Aug 18, 2015, at 10:32 AM, Stephen Mallette <sp...@gmail.com>
> >> wrote:
> >>
> >> I just wanted to quickly mention a minor new feature that will be
> >> available in 3.1.0. It is an addition to the utilities plugin and is
> >> basically a function called describeSteps(). When it is called from the
> >> Gremlin Console it will scan the classpath for all non-abstract Step
> >> implementations and print them in a table to display which important
> base
> >> classes and marker interfaces they extend/implement. This kind of
> >> information will be useful to those developing core
> API/TraversalStrategy
> >> implementations. You can see its usage in this gist:
> >>
> >> https://gist.github.com/spmallette/e12aebc8a747623059c4
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Gremlin-users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to gremlin-users+unsubscribe@googlegroups.com.
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/d/msgid/gremlin-users/CAA-H43-pxcn9SFhjLiRu7y7yWcjF7hZkkJeb%3DAfVJJBjZ5CHEw%40mail.gmail.com
> >> <
> https://groups.google.com/d/msgid/gremlin-users/CAA-H43-pxcn9SFhjLiRu7y7yWcjF7hZkkJeb%3DAfVJJBjZ5CHEw%40mail.gmail.com?utm_medium=email&utm_source=footer
> >
> >> .
> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Gremlin-users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to gremlin-users+unsubscribe@googlegroups.com.
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/d/msgid/gremlin-users/BA0F5FFE-239B-43DB-B3FE-A4C811D7572C%40gmail.com
> >> <
> https://groups.google.com/d/msgid/gremlin-users/BA0F5FFE-239B-43DB-B3FE-A4C811D7572C%40gmail.com?utm_medium=email&utm_source=footer
> >
> >> .
> >> For more options, visit https://groups.google.com/d/optout.
> >>
>
>
Re: [TinkerPop] describeSteps()
Posted by Marko Rodriguez <ok...@gmail.com>.
Hey,
I don't think its a useful feature and not something worth maintaining/exposing.
HasStep --- okay, so its a filter. ? … parameters, arguments… ? What does it do? What types does it take? What types does it emit? by() modulation?
> I don't see why that's a problem really - the table is dynamically driven.
> If we refactor, it's really not that big a deal to change.
Seems you would only use it in the context of a REPL as its a toString() like describeGraph(). For describeGraph(), makes a lot of sense as Features are very "for the user." For steps, not so much. Its so low-level that to give us (TinkerPop) more degrees of freedom at the instruction level, why ground it for the general user? Especially so early in the game at 3.1.0. If the user depends on that table to be as it is at 3.1.0+ … damn, locked in. I think its way to early to start making such promises.
>> 2. We don't have a DSL path yet.
>>
>
> we haven't discussed all the goals of 3.1.0 but the approach to DSLs should
> be part of that release - so in that sense it doesn't seem premature to me
> to have this feature in that branch.
Why should 3.1.0 have DSL? It would be good, but not forced. Moreover, describeSteps() doesn't really help for DSL constructions. You would go to the JavaDoc.
- What are all the steps?
http://tinkerpop.incubator.apache.org/javadocs/3.0.0-incubating/full/org/apache/tinkerpop/gremlin/process/traversal/step/filter/package-summary.html
- What is this particular step?
http://tinkerpop.incubator.apache.org/javadocs/3.0.0-incubating/full/org/apache/tinkerpop/gremlin/process/traversal/step/filter/HasStep.html
- What is the paragraph description of what it does?
… we should put our effort in better JavaDoc :D
- What interfaces does it implement?
http://tinkerpop.incubator.apache.org/javadocs/3.0.0-incubating/full/org/apache/tinkerpop/gremlin/process/traversal/step/HasContainerHolder.html
- What are those interfaces paragraph descriptions?
… again, better JavaDoc is needed.
A runtime toString() table of 1/4 of that information doesn't seem useful especially against the backdrop of users depending on it (as we all know, users do crazy things once you expose stuff).
> Having it as a utility allows us to generate it into the docs in real-time
> (not as some static data we have to manage manually). I also believe that
> a table is helpful from both a development and QA perspective. javadoc
> doesn't make it as easy to see in once place what all the relationships are
> among the steps. Finally, there will be steps outside of those maintained
> by TinkerPop and since this utility operates by doing a scan of the
> classpath for Step implementations, it will capture those on the classpath
> of the console as well and work them into the table.
We have to be very careful about letting people consider "steps outside" TinkerPop. This is something TraversalStrategy work has taught us. Unless you are a graph systems vendor (and I have ideas for constraining them), you should not be creating steps outside of TinkerPop. This is the idea of a static "Gremlin instruction set." Another reason why hiding steps and all this low-level stuff is important at this point in time.
I would remove it. However, at least, put it into a feature branch and not into master/.
Thanks,
Marko.
http://markorodriguez.com
>
>
>
> On Tue, Aug 18, 2015 at 3:06 PM, Marko Rodriguez <ok...@gmail.com>
> wrote:
>
>> Hi Stephen,
>>
>> I wouldn't add this just yet. I would not promote "normal users" working
>> with Steps directly as:
>>
>> 1. There typing will likely change soon given the work in "Gremlin
>> Traversal Machine and Language."
>> 2. We don't have a DSL path yet.
>> 3. The interface API will most likely change as well.
>>
>> Finally, I don't know what use this would have as a "runtime call." If
>> someone is developing a traversal language using the "instruction set" of
>> Gremlin, they will most likely be in JavaDoc-land, not in
>> describeSteps()-land. ??
>>
>> Perhaps, for now, you can pull this into a feature branch.
>>
>> Thanks,
>> Marko.
>>
>> http://markorodriguez.com
>>
>> On Aug 18, 2015, at 10:32 AM, Stephen Mallette <sp...@gmail.com>
>> wrote:
>>
>> I just wanted to quickly mention a minor new feature that will be
>> available in 3.1.0. It is an addition to the utilities plugin and is
>> basically a function called describeSteps(). When it is called from the
>> Gremlin Console it will scan the classpath for all non-abstract Step
>> implementations and print them in a table to display which important base
>> classes and marker interfaces they extend/implement. This kind of
>> information will be useful to those developing core API/TraversalStrategy
>> implementations. You can see its usage in this gist:
>>
>> https://gist.github.com/spmallette/e12aebc8a747623059c4
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Gremlin-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to gremlin-users+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/gremlin-users/CAA-H43-pxcn9SFhjLiRu7y7yWcjF7hZkkJeb%3DAfVJJBjZ5CHEw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/gremlin-users/CAA-H43-pxcn9SFhjLiRu7y7yWcjF7hZkkJeb%3DAfVJJBjZ5CHEw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Gremlin-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to gremlin-users+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/gremlin-users/BA0F5FFE-239B-43DB-B3FE-A4C811D7572C%40gmail.com
>> <https://groups.google.com/d/msgid/gremlin-users/BA0F5FFE-239B-43DB-B3FE-A4C811D7572C%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
Re: [TinkerPop] describeSteps()
Posted by Stephen Mallette <sp...@gmail.com>.
>
> 1. There typing will likely change soon given the work in "Gremlin
> Traversal Machine and Language."
>
I don't see why that's a problem really - the table is dynamically driven.
If we refactor, it's really not that big a deal to change.
> 2. We don't have a DSL path yet.
>
we haven't discussed all the goals of 3.1.0 but the approach to DSLs should
be part of that release - so in that sense it doesn't seem premature to me
to have this feature in that branch.
> Finally, I don't know what use this would have as a "runtime call." If
> someone is developing a traversal language using the "instruction set" of
> Gremlin, they will most likely be in JavaDoc-land, not in
> describeSteps()-land. ??
>
Having it as a utility allows us to generate it into the docs in real-time
(not as some static data we have to manage manually). I also believe that
a table is helpful from both a development and QA perspective. javadoc
doesn't make it as easy to see in once place what all the relationships are
among the steps. Finally, there will be steps outside of those maintained
by TinkerPop and since this utility operates by doing a scan of the
classpath for Step implementations, it will capture those on the classpath
of the console as well and work them into the table.
On Tue, Aug 18, 2015 at 3:06 PM, Marko Rodriguez <ok...@gmail.com>
wrote:
> Hi Stephen,
>
> I wouldn't add this just yet. I would not promote "normal users" working
> with Steps directly as:
>
> 1. There typing will likely change soon given the work in "Gremlin
> Traversal Machine and Language."
> 2. We don't have a DSL path yet.
> 3. The interface API will most likely change as well.
>
> Finally, I don't know what use this would have as a "runtime call." If
> someone is developing a traversal language using the "instruction set" of
> Gremlin, they will most likely be in JavaDoc-land, not in
> describeSteps()-land. ??
>
> Perhaps, for now, you can pull this into a feature branch.
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
> On Aug 18, 2015, at 10:32 AM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
> I just wanted to quickly mention a minor new feature that will be
> available in 3.1.0. It is an addition to the utilities plugin and is
> basically a function called describeSteps(). When it is called from the
> Gremlin Console it will scan the classpath for all non-abstract Step
> implementations and print them in a table to display which important base
> classes and marker interfaces they extend/implement. This kind of
> information will be useful to those developing core API/TraversalStrategy
> implementations. You can see its usage in this gist:
>
> https://gist.github.com/spmallette/e12aebc8a747623059c4
>
> --
> You received this message because you are subscribed to the Google Groups
> "Gremlin-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gremlin-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gremlin-users/CAA-H43-pxcn9SFhjLiRu7y7yWcjF7hZkkJeb%3DAfVJJBjZ5CHEw%40mail.gmail.com
> <https://groups.google.com/d/msgid/gremlin-users/CAA-H43-pxcn9SFhjLiRu7y7yWcjF7hZkkJeb%3DAfVJJBjZ5CHEw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Gremlin-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gremlin-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gremlin-users/BA0F5FFE-239B-43DB-B3FE-A4C811D7572C%40gmail.com
> <https://groups.google.com/d/msgid/gremlin-users/BA0F5FFE-239B-43DB-B3FE-A4C811D7572C%40gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>