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