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 <[email protected]>
> 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 <[email protected]>
>> 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 [email protected].
>> 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 [email protected].
>> 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.
>>
