Hello Matt, > - 639 <https://issues.apache.org/jira/browse/TINKERPOP3-639> (select and > selectList). There is already PR#57
I'm still not sure this is the path that we want to go down. I just see rippling requirements of xxxList or xxxMap falling from such a choice. > - 619 <https://issues.apache.org/jira/browse/TINKERPOP3-619> (select > should not throw). There was some progress on choosing the desired > behavior, but it sounds like a final decision is pending. This is doable. I suspect a no-result for when nothing binds --- like how filter() works (i.e. while(true) { if(hasSomething) return something;}) > - 652 <https://issues.apache.org/jira/browse/TINKERPOP3-652> (select > from Map explicitly). Is it a good idea to require Scope.local to do > select from Map? Or is selectKeys more appealing? This is a good one. I just don't like the select(local,"a","b") in this context as it makes MatchStep look ugly. However, it is probably the way to go and only MatchStep usage would be effected. SelectGlobalStep, SelectOneGlobalStep, SelectLocalStep, and SelectOneLocalStep. eek. Lots of "stuff" but yea, the Scope concept should propagate to here. What would be crazy is g.V.out.select(local,"name","age")…….. gnarly. I always wanted Element to implement Map, but there were reason (I forget) why it wouldn't work. If it did, then has() would work on Maps. hashMapStep.has("a").has("a",eq(32)) Instead, for such situations, we have where(). hasMapStep.where("a",eq(32)) We don't have where("a"). Be easy to add. > Not trying to rush anyone, but I have cycles to spend on this over the next > couple of weeks. HTH, Marko. http://markorodriguez.com
